[要約] RFC 8972は、Simple Two-Way Active Measurement Protocol (STAMP) のオプショナル拡張に関する文書です。この文書の目的は、ネットワークのパフォーマンス測定をより柔軟に行うための追加機能を提供することにあります。利用場面としては、ネットワークの遅延やジッターの計測、パケットロスの検出、サービス品質の監視などが挙げられます。
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8972 X. Min
Updates: 8762 ZTE Corp.
Category: Standards Track H. Nydell
ISSN: 2070-1721 Accedian Networks
R. Foote
Nokia
A. Masputra
Apple Inc.
E. Ruffini
OutSys
January 2021
Simple Two-Way Active Measurement Protocol Optional Extensions
単純な双方向アクティブ測定プロトコルオプションの拡張
Abstract
概要
This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.
この文書では、パフォーマンスメトリックの測定を可能にする簡単な双方向アクティブ測定プロトコル（スタンプ）へのオプションの拡張機能について説明します。この文書はスタンプテストセッション識別子も定義され、したがってRFC 8762を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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/rfc8972.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8972で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Acronyms
2.2. Requirements Language
3. STAMP Test Session Identifier
4. TLV Extensions to STAMP
4.1. Extra Padding TLV
4.2. Location TLV
4.2.1. Location Sub-TLVs
4.2.2. Theory of Operation of Location TLV
4.3. Timestamp Information TLV
4.4. Class of Service TLV
4.5. Direct Measurement TLV
4.6. Access Report TLV
4.7. Follow-Up Telemetry TLV
4.8. HMAC TLV
5. IANA Considerations
5.1. STAMP TLV Types Subregistry
5.2. STAMP TLV Flags Subregistry
5.3. STAMP Sub-TLV Types Subregistry
5.4. STAMP Synchronization Sources Subregistry
5.5. STAMP Timestamping Methods Subregistry
5.6. STAMP Return Codes Subregistry
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defines the STAMP base functionalities. This document specifies the use of optional extensions that use Type-Length-Value (TLV) encoding. Such extensions enhance the STAMP base functions, such as measurement of one-way and round-trip delay, latency, packet loss, packet duplication, and out-of-order delivery of test packets. This specification defines optional STAMP extensions, their formats, and the theory of operation. Also, a STAMP Test Session Identifier is defined as an update of the base STAMP specification [RFC8762].
単純な双方向アクティブ測定プロトコル（スタンプ）[RFC8762]スタンプベース機能を定義します。このドキュメントは、type-length-value（TLV）エンコーディングを使用するオプションの拡張機能の使用を指定します。そのような拡張は、一方向および往復遅延の測定、待ち時間、パケット損失、パケットの重複、およびテストパケットの乱数の配信などのスタンプ基本機能を強化する。この仕様は、オプションのスタンプ拡張、それらのフォーマット、および操作の理論を定義します。また、スタンプテストセッション識別子は、ベーススタンプ仕様[RFC8762]の更新として定義されています。
BDS BeiDou Navigation Satellite System
BDS BEIDOUナビゲーション衛星システム
BITS Building Integrated Timing Supply
統合タイミング供給を構築するビット
CoS Class of Service
COSのサービスクラス
DSCP Differentiated Services Code Point
DSCP差別化サービスコードポイント
ECN Explicit Congestion Notification
ECNの明示的な輻輳通知
GLONASS Global Orbiting Navigation Satellite System
グローナスグローバルな旋回ナビゲーション衛星システム
GPS Global Positioning System [GPS]
GPSグローバルポジショニングシステム[GPS]
HMAC Hashed Message Authentication Code
HMACハッシュメッセージ認証コード
LORAN-C Long Range Navigation System Version C
LORAN-CロングレンジナビゲーションシステムバージョンC.
MBZ Must Be Zero
MBZはゼロでなければなりません
NTP Network Time Protocol [RFC5905]
NTPネットワークタイムプロトコル[RFC5905]
PMF Performance Measurement Function
PMF性能測定機能
PTP Precision Time Protocol [IEEE.1588.2008]
PTP精密時間プロトコル[IEEE.1588.2008]
RP Reverse Path
RPリバースパス
SMI Structure of Management Information
管理情報のSMI構造
SSID STAMP Session Identifier
SSIDスタンプセッションID
SSU Synchronization Supply Unit
SSU同期供給装置
STAMP Simple Two-way Active Measurement Protocol
スタンプ単純な双方向能動測定プロトコル
TLV Type-Length-Value
TLV Type-Length-Value
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The STAMP Session-Sender transmits test packets to the STAMP Session-Reflector. The STAMP Session-Reflector receives the Session-Sender's packet and acts according to the configuration and optional control information communicated in the Session-Sender's test packet. 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 supports two modes: unauthenticated and authenticated. Unauthenticated STAMP test packets are compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packets.
スタンプセッション送信者はテストパケットをスタンプセッションリフレクタに送信します。スタンプセッションリフレクタはセッション送信者のパケットを受信し、セッション送信者のテストパケットに通信された構成およびオプションの制御情報に従って動作する。スタンプは2つの異なるテストパケットフォーマットを定義します：スタンプセッション送信者によって送信されたパケットの1つと、スタンプセッションリフレクタによって送信されたパケットの場合は1つ。スタンプは2つのモードをサポートしています：未認証と認証済み。認証されていないスタンプテストパケットは、認証されていないTwamp-Test [RFC5357]パケットを使用してワイヤーに互換性があります。
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.
デフォルトでは、スタンプは対称パケット、すなわちセッションリフレクタによって送信されたパケットのサイズがセッションリフレクタによって受信されたパケットのサイズに等しい。
A STAMP Session is identified by the 4-tuple (source and destination IP addresses, source and destination UDP port numbers). A STAMP Session-Sender MAY generate a locally unique STAMP Session Identifier (SSID). The SSID is a two-octet, non-zero unsigned integer. The SSID generation policy is implementation specific. [NUM-IDS-GEN] thoroughly analyzes common algorithms for identifier generation and their vulnerabilities. For example, an implementation can use the algorithms described in Section 7.1 of [NUM-IDS-GEN]. An implementation MUST NOT assign the same identifier to different STAMP test sessions. A Session-Sender MAY use the SSID to identify a STAMP test session. If the SSID is used, it MUST be present in each test packet of the given test session. In the unauthenticated mode, the SSID is located as displayed in Figure 1.
スタンプセッションは4タプル（送信元と宛先のIPアドレス、送信元、および宛先UDPポート番号）によって識別されます。スタンプセッション送信者は、ローカルに固有のスタンプセッション識別子（SSID）を生成することができる。SSIDは、ゼロ以外の符号なし整数です。SSID生成ポリシーは実装固有です。[NUM-IDS-GEN]識別子生成とその脆弱性について一般的なアルゴリズムを十分に分析します。例えば、実装は、セクション7.1の[NUM-IDS-GEN]に記載されているアルゴリズムを使用できます。実装は同じ識別子を異なるスタンプテストセッションに割り当ててはいけません。セッション送信者はSSIDを使用してスタンプテストセッションを識別することができます。SSIDが使用されている場合は、特定のテストセッションの各テストパケットに存在する必要があります。認証されていないモードでは、SSIDは図1に表示されているように配置されています。
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 | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| MBZ (28 octets) |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Format of an Extended STAMP Session-Sender Test Packet in Unauthenticated Mode
図1：認証されていないモードでの拡張スタンプセッション送信側テストパケットの形式
An implementation of the STAMP Session-Reflector that supports this specification MUST identify a STAMP Session using the SSID in combination with elements of the usual 4-tuple for the session. Before a test session commences, a Session-Reflector MUST be provisioned with all the elements that identify the STAMP Session. A STAMP Session-Reflector MUST discard non-matching STAMP test packets. The means of provisioning the STAMP Session identification is outside the scope of this specification. A conforming implementation of a STAMP Session-Reflector MUST copy the SSID value from the received test packet and put it into the reflected packet, as displayed in Figure 2.
この仕様をサポートするスタンプセッションリフレクタの実装は、セッションの通常の4タプルの要素と組み合わせてSSIDを使用してスタンプセッションを識別しなければなりません。テストセッションが開始される前に、Session-Reflectorをスタンプセッションを識別するすべての要素を使用してプロビジョニングする必要があります。スタンプセッションリフレクタは、一致しないスタンプテストパケットを廃棄する必要があります。スタンプセッション識別をプロビジョニングする手段は、この仕様の範囲外です。スタンプセッションリフレクタの適合的な実装は、受信したテストパケットからSSID値をコピーして、図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 | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Format of an Extended STAMP Session-Reflector Test Packet in Unauthenticated Mode
図2：認証されていないモードでの拡張スタンプセッションリフレクタテストパケットの形式
A STAMP Session-Reflector that does not support this specification will return the zeroed SSID field in the reflected STAMP test packet. The Session-Sender MAY stop the session if it receives a zeroed SSID field. An implementation of a Session-Sender MUST support control of its behavior in such a scenario. If the test session is not stopped, the Session-Sender can, for example, send a base STAMP packet [RFC8762] or continue transmitting STAMP test packets with the SSID.
この仕様をサポートしていないスタンプセッションリフレクタは、反射スタンプテストパケット内のゼロ化されたSSIDフィールドを返します。セッション送信者は、それがゼロ化されたSSIDフィールドを受信した場合にセッションを停止することがあります。セッション送信者の実装は、そのようなシナリオにおけるその動作の制御をサポートしなければなりません。テストセッションが停止されていない場合、Session-Senderは、たとえばベーススタンプパケット[RFC8762]を送信することも、SSIDを使用してスタンプテストパケットを送信することもできます。
The location of the SSID field in the authenticated mode is shown in Figures 3 and 4.
認証モードのSSIDフィールドの位置は図3および図4に示されています。
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 | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| MBZ (68 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Format of an Extended STAMP Session-Sender Test Packet in Authenticated Mode
図3：認証モードでの拡張スタンプセッション送信者テストパケットの形式
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 | SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (4 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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Format of an Extended STAMP Session-Reflector Test Packet in Authenticated Mode
図4：認証モードにおける拡張スタンプセッションリフレクタテストパケットのフォーマット
The Type-Length-Value (TLV) encoding scheme provides a flexible extension mechanism for optional informational elements. TLV is an optional field in the STAMP test packet. Multiple TLVs MAY be placed in a STAMP test packet. Additional TLVs may be enclosed within a given TLV, subject to the semantics of the (outer) TLV in question. TLVs have a one-octet STAMP TLV Flags field, a one-octet Type field, and a two-octet Length field that is equal to the length of the Value field in octets. If a Type value for a TLV or sub-TLV is in the range for Private Use [RFC8126], the length MUST be at least 4, and the first four octets MUST be that vendor's Structure of Management Information (SMI) Private Enterprise Code, as recorded in IANA's "SMI Network Management Private Enterprise Codes" subregistry, in network octet order. The rest of the Value field is private to the vendor. The following sections describe the use of TLVs for STAMP that extend the STAMP capability beyond its base specification.
type-length-value（TLV）符号化方式は、オプションの情報要素のための柔軟な拡張メカニズムを提供します。TLVはスタンプテストパケットのオプションのフィールドです。複数のTLVをスタンプテストパケットに配置することができます。問題の（外側）TLVの意味論を条件として、与えられたTLV内に追加のTLV内に囲まれてもよい。TLVSには、1オクテットスタンプTLVフラグフィールド、1オクテットタイプフィールド、およびオクテット内の値フィールドの長さに等しい2オクテット長フィールドがあります。TLVまたはSUB-TLVの型の値がプライベート使用の範囲内である場合は、LFC8126の範囲内で、長さは少なくとも4でなければならず、最初の4オクテットはそのベンダーの管理情報（SMI）プライベートエンタープライズコードの構造でなければなりません。IANAの「SMIネットワーク管理プライベートエンタープライズコード」サブリュージストリートで記録されている場合、ネットワークオクテットの順序で。残りの値フィールドはベンダーに非公開です。次のセクションでは、スタンプ機能を基本仕様を超えて拡張するスタンプ用のTLVの使用について説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TLV Format in a STAMP Extended Packet
図5：スタンプ拡張パケット内のTLV形式
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. The detailed format and interpretation of flags defined in this specification are below.
スタンプTLVフラグ：8ビットフィールド。本明細書で定義されているフラグの詳細な形式と解釈は以下の通りです。
Type: A one-octet field that characterizes the interpretation of the Value field. It is allocated by IANA, as specified in Section 5.1.
型：値フィールドの解釈を特徴付ける1オクテットフィールド。セクション5.1で指定されているように、IANAによって割り当てられます。
Length: A two-octet field equal to the length of the Value field in octets.
長さ：オクテットの値フィールドの長さに等しい2オクテットフィールド。
Value: A variable-length field. Its interpretation and encoding are determined by the value of the Type field.
値：可変長フィールド。その解釈と符号化は、型フィールドの値によって決まります。
All multi-byte fields in TLVs defined in this specification are in network byte order.
この仕様で定義されているTLVのすべてのマルチバイトフィールドは、ネットワークバイト順にあります。
The format of the STAMP TLV Flags is displayed in Figure 6, and the location of flags is defined in Section 5.2.
スタンプTLVフラグのフォーマットは図6に表示され、フラグの位置はセクション5.2で定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|M|I|R|R|R|R|R|
+-+-+-+-+-+-+-+-+
Figure 6: STAMP TLV Flags Format
図6：スタンプTLVフラグフォーマット
The fields are defined as follows:
フィールドは次のように定義されています。
U (Unrecognized): A one-bit flag. A Session-Sender MUST set the U flag to 1 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the U flag to 1 if the Session-Reflector has not understood the TLV. Otherwise, the Session-Reflector MUST set the U flag in the reflected packet to 0.
U（認識されない）：1ビットのフラグ。セッション送信者は、拡張スタンプテストパケットを送信する前にUフラグを1に設定する必要があります。セッションリフレクタがTLVを理解していない場合、セッションリフレクタはUフラグを1に設定する必要があります。それ以外の場合、セッションリフレクタは反射パケット内のUフラグを0に設定する必要があります。
M (Malformed): A one-bit flag. A Session-Sender MUST set the M flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the M flag to 1 if the Session-Reflector determined the TLV is malformed, i.e., the Length field value is not valid for the particular type, or the remaining length of the extended STAMP packet is less than the size of the TLV. Otherwise, the Session-Reflector MUST set the M flag in the reflected packet to 0.
M（不正行為）：1ビットのフラグ。セッション送信者は、拡張スタンプテストパケットを送信する前にMフラグを0に設定する必要があります。セッションリフレクタがTLVが不正なことを決定した場合、すなわち長さフィールド値が特定のタイプに対して有効であるか、または拡張スタンプパケットの残りの長さがサイズよりも小さい場合、セッションリフレクタはMフラグを1に設定する必要があります。TLVの。それ以外の場合、セッションリフレクタは反射パケット内のMフラグを0に設定する必要があります。
I (Integrity): A one-bit flag. A Session-Sender MUST set the I flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the I flag to 1 if the STAMP extensions have failed HMAC verification (Section 4.8). Otherwise, the Session-Reflector MUST set the I flag in the reflected packet to 0.
I（整合性）：ワンビットフラグ。拡張スタンプテストパケットを送信する前に、セッション送信者がiフラグを0に設定する必要があります。スタンプ拡張にHMAC検証が失敗した場合は、セッションリフレクタがIフラグを1に設定する必要があります（セクション4.8）。それ以外の場合、セッションリフレクタは反射パケット内のIフラグを0に設定する必要があります。
R: Reserved flags for future use. These flags MUST be zeroed on transmit and ignored on receipt.
R：将来の使用のための予約済みフラグ。これらのフラグは送信時にゼロ化され、受信時に無視されなければなりません。
A STAMP node, whether Session-Sender or Session-Reflector, receiving a test packet MUST determine whether the packet is a base STAMP packet or whether it includes one or more TLVs. The node MUST compare the value in the Length field of the UDP header and the length of the base STAMP test packet in the mode, unauthenticated or authenticated, based on the configuration of the particular STAMP test session. If the difference between the two values is greater than the length of the UDP header, then the test packet includes one or more STAMP TLVs that immediately follow the base STAMP test packet. A Session-Reflector that does not support STAMP extensions will not process but copy them into the reflected packet, as defined in Section 4.3 of [RFC8762]. A Session-Reflector that supports TLVs will indicate specific TLVs that it did not process by setting the U flag to 1 in those TLVs.
テストパケットを受信したセッション送信者またはセッションリフレクタであれ、Stampノード、またはセッションリフレクタが、パケットがベーススタンプパケットであるか、または1つ以上のTLVを含むかどうかを判断する必要があります。ノードは、特定のスタンプテストセッションの構成に基づいて、UDPヘッダの長さフィールドとベーススタンプテストパケットの長さとベーススタンプテストパケットの長さとを比較する必要があります。2つの値の差がUDPヘッダーの長さより大きい場合、テストパケットはベーススタンプテストパケットにすぐに従う1つ以上のスタンプTLVを含む。Stamp Extensionsをサポートしていないセッションリフレクタは、[RFC8762]のセクション4.3で定義されているように、処理されずに反射パケットにコピーします。TLVSをサポートするセッションリフレクタは、それらのTLVのUフラグを1に設定して処理しなかった特定のTLVを示します。
A STAMP Session-Sender that has received a reflected STAMP test packet with extension TLVs MUST validate each TLV:
Extension TLVを持つ反射スタンプテストパケットを受信したスタンプセッション送信者は、各TLVを検証する必要があります。
* If the U flag is set, the STAMP system MUST skip the processing of the TLV.
* Uフラグが設定されている場合、スタンプシステムはTLVの処理をスキップする必要があります。
* If the M flag is set, the STAMP system MUST stop processing the remainder of the extended STAMP packet.
* Mフラグが設定されている場合、スタンプシステムは、拡張スタンプパケットの残りの部分の処理を停止しなければなりません。
* If the I flag is set, the STAMP system MUST discard all TLVs and MUST stop processing the remainder of the extended STAMP packet.
* Iフラグが設定されている場合、スタンプシステムはすべてのTLVを破棄し、拡張スタンプパケットの残りの部分の処理を停止する必要があります。
* If an implementation of a Session-Reflector does not recognize the Type field value, it MUST include a copy of the TLV in the reflected STAMP packet. The Session-Reflector MUST set the U flag to 1. The Session-Reflector MUST skip the processing of the unrecognized TLV.
* セッションリフレクタの実装がタイプフィールド値を認識しない場合は、反射スタンプパケット内のTLVのコピーを含める必要があります。セッションリフレクタはUフラグを1に設定する必要があります。セッションリフレクタは、認識されていないTLVの処理をスキップする必要があります。
* If a TLV is malformed, the processing of extension TLVs MUST be stopped. The Session-Reflector MUST copy the remainder of the received extended STAMP packet into the reflected STAMP packet. The Session-Reflector MUST set the M flag to 1.
* TLVが不正行為された場合は、拡張子TLVの処理を停止する必要があります。セッションリフレクタは、受信した拡張スタンプパケットの残りの部分を反射スタンプパケットにコピーする必要があります。セッションリフレクタはMフラグを1に設定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extra Padding ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Extra Padding TLV
図7：余分なパディングTLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 1 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値1はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field equal to the length of the Extra Padding field in octets.
長さ：オクテットの余分なパディングフィールドの長さに等しい2オクテットフィールド。
Extra Padding: This field SHOULD be filled by a sequence of pseudorandom numbers. The field MAY be filled with all zeros. An implementation MUST control the content of the Extra Padding field.
追加のパディング：このフィールドは、シーケンスの疑似乱数番号で埋められます。フィールドはすべてのゼロでいっぱいになることがあります。実装は追加のパディングフィールドの内容を制御する必要があります。
The Extra Padding TLV is similar to the Packet Padding field in a TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is RECOMMENDED to perform a STAMP test using test packets that are larger than the base STAMP packet [RFC8762]. The length of the base STAMP packet is 44 octets in the unauthenticated mode or 112 octets in the authenticated mode. The Extra Padding TLV MAY be present more than one time in an extended STAMP test packet.
余分なパディングTLVは、TWAMP-TESTパケット[RFC5357]のパケットパディングフィールドと似ています。追加のパディングTLVの使用は、ベーススタンプパケット[RFC8762]よりも大きいテストパケットを使用してスタンプテストを実行することをお勧めします。ベーススタンプパケットの長さは、認証されていないモードの44オクテット、または認証モードの112オクテットです。余分なパディングTLVは、拡張スタンプテストパケットで複数回存在してもよい。
STAMP Session-Senders MAY include the variable-size Location TLV to query location information from the Session-Reflector. The Session-Sender MUST NOT fill any information fields except for the STAMP TLV Flags, Type, and Length fields. The Session-Reflector MUST verify that the TLV is well formed. If it is not, the Session-Reflector follows the procedure defined in Section 4 for a malformed TLV.
スタンプセッション送信者は、セッションリフレクタから位置情報を照会するための可変サイズの位置TLVを含み得る。session-senderは、スタンプTLVフラグ、TYPE、およびLENGTHフィールドを除く、情報フィールドを入力してはなりません。セッションリフレクタは、TLVが十分に形成されていることを検証する必要があります。そうでなければ、セッションリフレクタは不正な形式のTLVについてセクション4で定義されている手順に従います。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Location TLV
図8：場所TLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 2 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値2はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field equal to the length of the Value field in octets.
長さ：オクテットの値フィールドの長さに等しい2オクテットフィールド。
Destination Port: A two-octet UDP destination port number of the received STAMP packet.
宛先ポート：受信したスタンプパケットの2オクテットUDP宛先ポート番号。
Source Port: A two-octet UDP source port number of the received STAMP packet.
送信元ポート：受信スタンプパケットの2オクテットUDPソースポート番号。
Sub-TLVs: A sequence of sub-TLVs, as defined further in this section. The sub-TLVs are used by the Session-Sender to request location information with generic sub-TLV types, and the Session-Reflector responds with the corresponding more-specific sub-TLVs for the type of address (e.g., IPv4 or IPv6) used at the Session-Reflector.
サブTLVS：このセクションでさらに定義されているように、サブTLVのシーケンス。サブTLVは、セッション送信者によって一般的なサブTLVタイプを持つ場所情報を要求するために使用され、セッションリフレクタは使用されるアドレスの種類（例えば、IPv4またはIPv6）のために対応するより特定のサブTLVで応答する。セッションリフレクタで。
Note that all fields not filled by either a Session-Sender or Session-Reflector are transmitted with all bits set to zero.
セッション送信者またはセッションリフレクタのいずれかによって埋められないすべてのフィールドは、すべてのビットがゼロに設定されて送信されます。
A sub-TLV in the Location TLV uses the format displayed in Figure 5. Handling of the U and M flags in the sub-TLV is as defined in Section 4. The I flag MUST be set by a Session-Sender and Session-Reflector to 0 before transmission and its value ignored on receipt. The following types of sub-TLVs for the Location TLV are defined in this specification (Table 5 lists the Type values):
Location TLVのSUB-TLVは図5に表示されている形式を使用します.SUB-TLV内のUフラグとMフラグの処理はセクション4で定義されているとおりです。送信前に0に、その値は受信時に無視されます。この仕様では、場所TLVの次のSUB-TLVが定義されています（表5にタイプ値を示します）。
Source MAC Address sub-TLV: A 12-octet sub-TLV. The Type value is 1. The value of the Length field MUST be equal to 8. The Value field is an 8-octet MBZ field that MUST be zeroed on transmission and ignored on receipt.
ソースMACアドレスサブTLV：12オクテットサブTLV。タイプ値は1です.1フィールドの値は8に等しくなければなりません.valueフィールドは、送信時にゼロにゼロ化され、受信時に無視されなければならない8オクテットMBZフィールドです。
Source EUI-48 Address sub-TLV: A 12-octet sub-TLV that includes the EUI-48 source MAC address. The Type value is 2. The value of the Length field MUST be equal to 8.
ソースEUI-48アドレスSUB-TLV：EUI-48の送信元MACアドレスを含む12オクテットサブTLV。タイプ値は2です.1フィールドの値は8に等しくなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI-48 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Value Field of the Source EUI-48 Address Sub-TLV
図9：ソースEUI-48アドレスサブTLVの値フィールド
The Value field consists of the following fields (Figure 9):
値フィールドは、次のフィールドで構成されています（図9）。
EUI-48 Address: A six-octet field.
EUI-48アドレス：6オクテットフィールド。
MBZ: A two-octet field. It MUST be zeroed on transmission and ignored on receipt.
MBZ：2オクテットフィールド。送信時にゼロにゼロにされ、受信時に無視されます。
Source EUI-64 Address sub-TLV: A 12-octet sub-TLV that includes the EUI-64 source MAC address. The Type value is 3. The value of the Length field MUST be equal to 8. The Value field consists of an eight-octet EUI-64 field.
ソースEUI-64アドレスSUB-TLV：EUI-64ソースMACアドレスを含む12オクテットサブTLV。タイプ値は3です.1フィールドの値は8に等しくなければなりません.valueフィールドは、8オクテットEUI-64フィールドで構成されています。
Destination IP Address sub-TLV: A 20-octet sub-TLV. The Type value is 4. The value of the Length field MUST be equal to 16. The Value field consists of a 16-octet MBZ field that MUST be zeroed on transmit and ignored on receipt.
宛先IPアドレスSUB-TLV：20オクテットサブTLV。タイプ値は4です.16桁のフィールドの値は16に等しくなければなりません.valueフィールドは、送信時にゼロ化され、受信時に無視されなければならない16オクテットMBZフィールドで構成されています。
Destination IPv4 Address sub-TLV: A 20-octet sub-TLV that includes the IPv4 destination address. The Type value is 5. The value of the Length field MUST be equal to 16.
宛先IPv4アドレスSUB-TLV：IPv4宛先アドレスを含む20オクテットサブTLV。タイプ値は5です。長さフィールドの値は16に等しくなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MBZ (12 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 Address in a Sub-TLV's Value Field
図10：サブTLVの値フィールドのIPv4アドレス
The Value field consists of the following fields (Figure 10):
値フィールドは、次のフィールドで構成されています（図10）。
IPv4 Address: A four-octet field.
IPv4アドレス：4オクテットフィールド。
MBZ: A 12-octet field. It MUST be zeroed on transmit and ignored on receipt.
MBZ：12オクテットフィールド。送信時にゼロ化され、受信時に無視されます。
Destination IPv6 Address sub-TLV: A 20-octet sub-TLV that includes the IPv6 destination address. The Type value is 6. The value of the Length field MUST be equal to 16. The Value field is a 16-octet IPv6 Address field.
宛先IPv6アドレスSUB-TLV：IPv6宛先アドレスを含む20オクテットサブTLV。タイプ値は6です.16項目の値は16に等しくなければなりません.valueフィールドは16オクテットのIPv6アドレスフィールドです。
Source IP Address sub-TLV: A 20-octet sub-TLV. The Type value is 7. The value of the Length field MUST be equal to 16. The Value field is a 16-octet MBZ field that MUST be zeroed on transmit and ignored on receipt.
ソースIPアドレスSUB-TLV：20オクテットサブTLV。タイプ値は7です.11桁の値は16に等しくなければなりません.valueフィールドは、送信時にゼロにゼロにする必要がある16オクテットMBZフィールドです。
Source IPv4 Address sub-TLV: A 20-octet sub-TLV that includes the IPv4 source address. The Type value is 8. The value of the Length field MUST be equal to 16. The Value field consists of the following fields (Figure 10):
ソースIPv4アドレスSUB-TLV：IPv4ソースアドレスを含む20オクテットサブTLV。タイプ値は8です.15の値は16に等しくなければなりません.valueフィールドは、次のフィールドで構成されています（図10）。
IPv4 Address: A four-octet field.
IPv4アドレス：4オクテットフィールド。
MBZ: A 12-octet field. It MUST be zeroed on transmit and ignored on receipt.
MBZ：12オクテットフィールド。送信時にゼロ化され、受信時に無視されます。
Source IPv6 Address sub-TLV: A 20-octet sub-TLV that includes the IPv6 source address. The Type value is 9. The value of the Length field MUST be equal to 16. The Value field is a 16-octet IPv6 Address field.
ソースIPv6アドレスSUB-TLV：IPv6の送信元アドレスを含む20オクテットサブTLV。タイプ値は9です.11桁の値は16に等しくなければなりません.valueフィールドは16オクテットのIPv6アドレスフィールドです。
The Session-Reflector that received an extended STAMP packet with the Location TLV MUST include in the reflected packet the Location TLV with a length equal to the Location TLV length in the received packet. Based on the local policy, the Session-Reflector MAY leave some fields unreported by filling them with zeroes. An implementation of the stateful Session-Reflector MUST provide control for managing such policies.
位置TLVを有する拡張スタンプパケットを受信したセッションリフレクタは、受信パケット内の位置TLV長に等しい長さを有する位置TLVを反映したパケットに含める必要がある。ローカルポリシーに基づいて、セッションリフレクタは、それらをゼロに埋めることによっていくつかのフィールドをエクセルなままにすることができます。ステートフルセッションリフレクタの実装は、そのようなポリシーを管理するための制御を提供しなければならない。
A Session-Sender MAY include the Source MAC Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Source MAC Address sub-TLV, it MUST include the Source EUI-48 Address sub-TLV if the source MAC address of the received extended test packet is in EUI-48 format. And the Session-Reflector MUST copy the value of the source MAC address in the EUI-48 field. Otherwise, the Session-Reflector MUST use the Source EUI-64 Address sub-TLV and MUST copy the value of the Source MAC Address from the received packet into the EUI-64 field. If the received extended STAMP test packet does not have the Source MAC Address, the Session-Reflector MUST zero the EUI-64 field before transmitting the reflected packet.
セッション送信者は、位置TLV内の送信元MACアドレスサブTLVを含み得る。セッションリフレクタがソースMACアドレスサブTLVを含む場所TLVを受信すると、受信した拡張テストパケットの送信元MACアドレスがEUI-48形式である場合、ソースEUI-48アドレスサブTLVを含める必要があります。セッションリフレクタは、EUI-48フィールドに送信元MACアドレスの値をコピーする必要があります。それ以外の場合、セッションリフレクタはソースEUI-64アドレスサブTLVを使用しなければならず、受信したパケットから送信元MACアドレスの値をEUI-64フィールドにコピーする必要があります。受信した拡張スタンプテストパケットに送信元MACアドレスがない場合、セッションリフレクタは反射されたパケットを送信する前にEUI-64フィールドをゼロにしなければなりません。
A Session-Sender MAY include the Destination IP Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Destination IP Address sub-TLV, it MUST include the Destination IPv4 Address sub-TLV if the source IP address of the received extended test packet is of the IPv4 address family. And the Session-Reflector MUST copy the value of the destination IP address in the IPv4 Address field. Otherwise, the Session-Reflector MUST use the Destination IPv6 Address sub-TLV and MUST copy the value of the destination IP address from the received packet into the IPv6 Address field.
セッション送信者は、位置TLV内の宛先IPアドレスサブTLVを含み得る。セッションリフレクタが宛先IPアドレスサブTLVを含む場所TLVを受信すると、受信した拡張テストパケットの送信元IPアドレスがIPv4アドレスファミリの場合、宛先IPv4アドレスサブTLVを含める必要があります。セッションリフレクタは、IPv4アドレスフィールドに宛先IPアドレスの値をコピーする必要があります。それ以外の場合、セッションリフレクタは宛先IPv6アドレスサブTLVを使用しなければならず、受信したパケットから宛先IPアドレスの値をIPv6アドレスフィールドにコピーする必要があります。
A Session-Sender MAY include the Source IP Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Source IP Address sub-TLV, it MUST include the Source IPv4 Address sub-TLV if the source IP address of the received extended test packet is of the IPv4 address family. And the Session-Reflector MUST copy the value of the source IP address in the IPv4 Address field. Otherwise, the Session-Reflector MUST use the Source IPv6 Address sub-TLV and MUST copy the value of the source IP address from the received packet into the IPv6 Address field.
セッション送信者は、場所TLV内の送信元IPアドレスサブTLVを含み得る。セッションリフレクタが送信元IPアドレスサブTLVを含む場所TLVを受信した場合、受信した拡張テストパケットの送信元IPアドレスがIPv4アドレスファミリの場合、ソースIPv4アドレスサブTLVを含める必要があります。セッションリフレクタは、IPv4アドレスフィールドに送信元IPアドレスの値をコピーする必要があります。それ以外の場合、セッションリフレクタはソースIPv6アドレスサブTLVを使用する必要があり、受信したパケットから送信元IPアドレスの値をIPv6アドレスフィールドにコピーする必要があります。
The Location TLV MAY be used to determine the last-hop IP addresses, ports, and last-hop MAC address for STAMP packets. The MAC address can indicate a path switch on the last hop. The IP addresses and UDP ports will indicate if there is a NAT router on the path. It allows the Session-Sender to identify the IP address of the Session-Reflector behind the NAT and detect changes in the NAT mapping that could result in sending the STAMP packets to the wrong Session-Reflector.
位置TLVを使用して、スタンプパケットの最後のホップIPアドレス、ポート、およびラストホップMACアドレスを決定することができる。MACアドレスは、最後のホップのパススイッチを示すことができます。IPアドレスとUDPポートは、パスにNATルータがあるかどうかを示します。これにより、Session-SenderはNATの後ろのセッションリフレクタのIPアドレスを識別し、スタンプパケットを間違ったセッションリフレクタに送信する可能性があるNATマッピングの変更を検出できます。
The STAMP Session-Sender MAY include the Timestamp Information TLV to request information from the Session-Reflector. The Session-Sender MUST NOT fill any information fields except for STAMP TLV Flags, Type, and Length. All other fields MUST be filled with zeroes. The Session-Reflector MUST validate the Length value of the TLV. If the value of the Length field is invalid, the Session-Reflector follows the procedure defined in Section 4 for a malformed TLV.
スタンプセッション送信者は、セッションリフレクタから情報を要求するためのタイムスタンプ情報TLVを含み得る。Session-Senderは、スタンプTLVフラグ、TYPE、およびLENGTHを除く情報フィールドを入力してはいけません。他のすべてのフィールドはゼロで埋められなければなりません。セッションリフレクタはTLVの長さ値を検証する必要があります。長さフィールドの値が無効な場合、セッションリフレクタは不正な形式のTLVのセクション4で定義されているプロシージャに従います。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sync Src In | Timestamp In | Sync Src Out | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Timestamp Information TLV
図11：タイムスタンプ情報TLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 3 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値3はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field, set equal to the length of the Value field in octets (Figure 5).
長さ：2オクテットフィールドは、オクテットの値フィールドの長さに等しく設定されています（図5）。
Sync Src In: A one-octet field that characterizes the source of clock synchronization at the ingress of a Session-Reflector. There are several methods for synchronizing the clock, e.g., the Network Time Protocol (NTP) [RFC5905]. Table 7 lists the possible values.
SYNC SRC IN：セッションリフレクタの入力でクロック同期のソースを特徴付ける1オクテットフィールド。クロック、例えばネットワークタイムプロトコル（NTP）[RFC5905]を同期させるためのいくつかの方法がある。表7に可能な値を示します。
Timestamp In: A one-octet field that characterizes the method by which the ingress of the Session-Reflector obtained the timestamp T2. A timestamp may be obtained with hardware assistance via a software API from a local wall clock or from a remote clock (the latter is referred to as a "control plane"). Table 9 lists the possible values.
タイムスタンプIN：セッションリフレクタの入力がタイムスタンプT2を取得した方法を特徴付ける1オクテットフィールド。タイムスタンプは、ローカルウォールクロックまたはリモートクロックからのソフトウェアAPIを介したハードウェアアシストで取得することができる（後者は「コントロールプレーン」と呼ばれる）。表9に可能な値を示します。
Sync Src Out: A one-octet field that characterizes the source of clock synchronization at the egress of the Session-Reflector. Table 7 lists the possible values.
SYNC SRC OUT：セッションリフレクタの出力時のクロック同期のソースを特徴付ける1オクテットフィールド。表7に可能な値を示します。
Timestamp Out: A one-octet field that characterizes the method by which the egress of the Session-Reflector obtained the timestamp T3. Table 9 lists the possible values.
タイムスタンプOUT：セッションリフレクタの出力がタイムスタンプT3を取得した方法を特徴付ける1オクテットフィールド。表9に可能な値を示します。
Optional sub-TLVs: An optional variable-length field.
オプションのsub-tlvs：オプションの可変長フィールド。
The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in the STAMP test packet. The format of the CoS TLV is presented in Figure 12.
スタンプセッション送信者は、スタンプテストパケット内のサービスクラス（CoS）TLVを含み得る。COS TLVのフォーマットは図12に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP1 | DSCP2 |ECN| RP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Class of Service TLV
図12：サービスクラスTLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 4 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値4はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field, set equal to the value 4.
長さ：2オクテットフィールドは、値4に等しく設定します。
DSCP1: The Differentiated Services Code Point (DSCP) intended by the Session-Sender to be used as the DSCP value of the reflected test packet.
DSCP1：Session-Senderが反映したテストパケットのDSCP値として使用される微分サービスコードポイント（DSCP）。
DSCP2: The received value in the DSCP field at the ingress of the Session-Reflector.
DSCP2：セッションリフレクタの入力におけるDSCPフィールドの受信値。
ECN: The received value in the ECN field at the ingress of the Session-Reflector.
ECN：セッションリフレクタの入力におけるECNフィールドの受信値。
RP (Reverse Path): A two-bit field. A Session-Sender MUST set the value of the RP field to 0 on transmission.
RP（リバースパス）：2ビットフィールド。Session-Senderは、送信時にRPフィールドの値を0に設定する必要があります。
Reserved: A 16-bit field that MUST be zeroed on transmission and ignored on receipt.
予約済み：送信時にゼロ化され、受信時に無視されなければならない16ビットフィールド。
A STAMP Session-Reflector that receives a test packet with the CoS TLV MUST include the CoS TLV in the reflected test packet. Also, the Session-Reflector MUST copy the value of the DSCP and ECN fields of the IP header of the received STAMP test packet into the DSCP2 field in the reflected test packet. Finally, the Session-Reflector MUST use the local policy to verify whether the CoS corresponding to the value of the DSCP1 field is permitted in the domain. If it is, the Session-Reflector MUST set the DSCP field's value in the IP header of the reflected test packet equal to the value of the DSCP1 field of the received test packet. Otherwise, the Session-Reflector MUST use the DSCP value of the received STAMP packet and set the value of the RP field to 1. Upon receiving the reflected packet, if the value of the RP field is 0, the Session-Sender will save the DSCP and ECN values for analysis of the CoS in the reverse direction. If the value of the RP field in the received reflected packet is 1, only CoS in the forward direction can be analyzed.
COS TLVを使用してテストパケットを受信するスタンプセッションリフレクタは、反射テストパケットにCOS TLVを含めなければなりません。また、セッションリフレクタは、受信したスタンプテストパケットのIPヘッダーのDSCPフィールドとECNフィールドの値を反射テストパケットのDSCP2フィールドにコピーする必要があります。最後に、セッションリフレクタはローカルポリシーを使用して、DSCP1フィールドの値に対応するCOSがドメイン内で許可されているかどうかを確認する必要があります。そうであれば、セッションリフレクタは、受信したテストパケットのDSCP1フィールドの値に等しい反射テストパケットのIPヘッダーにDSCPフィールドの値を設定する必要があります。そうでなければ、セッションリフレクタは受信スタンプパケットのDSCP値を使用し、RPフィールドの値を1に設定する必要があります。反射パケットを受信すると、RPフィールドの値が0の場合、セッション送信者は保存します。 DSCPおよびECN値は、逆方向のCOSの分析のための値。受信した反射パケット内のRPフィールドの値が1である場合、順方向のCOSのみを分析することができる。
Re-mapping of CoS can be used to provide multiple services (e.g., 2G, 3G, LTE in mobile backhaul networks) over the same network. But if it is misconfigured, then it is often difficult to diagnose the root cause of excessive packet drops of higher-level service while packet drops for lower service packets are at a normal level. Using a CoS TLV in STAMP testing helps to troubleshoot the existing problem and also verify whether Diffserv policies are processing CoS as required by the configuration.
COSの再マッピングは、同じネットワーク上の複数のサービス（例えば、2G、3G、LTE）を提供するために使用することができる。しかし、それが誤って設定されている場合、下位サービスパケットのパケットドロップは通常のレベルにある間、高レベルのサービスの過度のパケットドロップの根本的な原因を診断することが困難です。スタンプテストでCOS TLVを使用すると、既存の問題のトラブルシューティングに役立ち、構成によって必要なようにDiffServポリシーがCOSの処理であるかどうかを確認します。
The Direct Measurement TLV enables collection of the number of in-profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session-Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine.
直接測定TLVは、それぞれセッション送信側およびセッションリフレクタによって送受信された特定のデータフローを形成するインプロファイルパケットの数、すなわち特定のデータフローを形成するパケットの集まりを可能にする。「インプロファイルパケット」の定義は、この文書の範囲外であり、判断するためにテスト演算子に任されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Tx counter (S_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Rx counter (R_RxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Tx counter (R_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Direct Measurement TLV
図13：直接測定TLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 5 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値5はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field equal to the length of the Value field in octets. The Length field value MUST equal 12 octets.
長さ：オクテットの値フィールドの長さに等しい2オクテットフィールド。長さフィールド値は12オクテットに等しくなければなりません。
Session-Sender Tx counter (S_TxC): A four-octet field. The Session-Sender MUST set its value equal to the number of the transmitted in-profile packets.
セッション送信者TXカウンタ（S_TXC）：4オクテットフィールド。セッション送信者は、送信されたプロファイルパケットの数に等しい値を設定する必要があります。
Session-Reflector Rx counter (R_RxC): A four-octet field. It MUST be zeroed by the Session-Sender on transmit and ignored by the Session-Reflector on receipt. The Session-Reflector MUST fill it with the value of in-profile packets received.
セッションリフレクタRXカウンタ（R_RXC）：4オクテットフィールド。Session-Senderによって、受信時にセッションリフレクタによって無視されます。セッションリフレクタは、受信したプロファイル内パケットの値で埋めなければなりません。
Session-Reflector Tx counter (R_TxC): A four-octet field. It MUST be zeroed by the Session-Sender and ignored by the Session-Reflector on receipt. The Session-Reflector MUST fill it with the value of the transmitted in-profile packets.
セッションリフレクタTXカウンタ（R_TXC）：4オクテットフィールド。それはセッション送信者によってゼロ化され、そして受信時にセッションリフレクターによって無視されなければなりません。セッションリフレクタは、送信されたプロファイルパケットの値に埋めなければなりません。
A Session-Sender MAY include the Direct Measurement TLV in a STAMP test packet. If the received STAMP test packet includes the Direct Measurement TLV, the Session-Reflector MUST include it in the reflected test packet. The Session-Reflector MUST copy the value from the S_TxC field of the received test packet into the same field of the reflected packet before its transmission.
セッション送信者は、スタンプテストパケット内の直接測定TLVを含み得る。受信スタンプテストパケットが直接測定TLVを含む場合、セッションリフレクタはそれを反射テストパケットに含める必要があります。セッションリフレクタは、受信したテストパケットのS_TXCフィールドからの値をその送信前に反射されたパケットの同じフィールドにコピーする必要があります。
A STAMP Session-Sender MAY include an Access Report TLV (Figure 14) to indicate changes to the access network status to the Session-Reflector. The definition of an access network is outside the scope of this document.
スタンプセッション送信者は、アクセスネットワークステータスへの変更をセッションリフレクタへの変更を示すためのアクセスレポートTLV（図14）を含み得る。アクセスネットワークの定義はこの文書の範囲外です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Resv | Return Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Access Report TLV
図14：アクセスレポートTLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 6 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値6はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field, set equal to the value 4.
長さ：2オクテットフィールドは、値4に等しく設定します。
ID (Access ID): A four-bit field that identifies the access network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) or non-3GPP (accesses that are not specified by 3GPP) [TS23501]. The value is one of the following:
ID（アクセスID）：アクセスネットワーク、例えば3GPP（3GPPで指定された無線アクセス技術）または非3GPP（3GPPで指定されていない）[TS23501]。値は次のいずれかです。
1: 3GPP Network
1：3GPPネットワーク
2: Non-3GPP Network
2：非3GPPネットワーク
All other values are invalid; a TLV that contains values other than '1' or '2' MUST be discarded.
他のすべての値は無効です。'1'または '2'以外の値を含むTLVは破棄されなければなりません。
Resv: A four-bit field that MUST be zeroed on transmission and ignored on receipt.
Resv：送信時にゼロにゼロにする必要があり、受信時に無視されなければならない4ビットのフィールド。
Return Code: A one-octet field that identifies the report signal, e.g., available or unavailable. The value is supplied to the STAMP endpoint through some mechanism that is outside the scope of this document. Section 5.6 lists the possible values.
戻りコード：レポート信号を識別する1オクテットフィールド、例えば、利用可能または使用不可。この文書の範囲外のメカニズムを介して、値はスタンプエンドポイントに供給されます。セクション5.6に可能な値を示します。
Reserved: A two-octet field that MUST be zeroed on transmission and ignored on receipt.
予約済み：送信時にゼロ化され、受信時に無視されなければならない2オクテットフィールド。
The STAMP Session-Sender that includes the Access Report TLV sets the value of the Access ID field according to the type of access network it reports on. Also, the Session-Sender sets the value of the Return Code field to reflect the operational state of the access network. The mechanism to determine the state of the access network is outside the scope of this specification. A STAMP Session-Reflector that received the test packet with the Access Report TLV MUST include the Access Report TLV in the reflected test packet. The Session-Reflector MUST set the value of the Access ID and Return Code fields equal to the values of the corresponding fields from the test packet it has received.
アクセスレポートを含むスタンプセッション送信者TLVは、それが報告するアクセスネットワークの種類に従ってアクセスIDフィールドの値を設定します。また、セッション送信者は、アクセスネットワークの動作状態を反映するように戻りコードフィールドの値を設定する。アクセスネットワークの状態を判断するメカニズムは、この仕様の範囲外です。アクセスレポートTLVを使用してテストパケットを受信したスタンプセッションリフレクタは、反射テストパケット内のアクセスレポートTLVを含める必要があります。セッションリフレクタは、受信したテストパケットからの対応するフィールドの値に等しいアクセスIDフィールドの値を設定する必要があります。
The Session-Sender MUST also arm a retransmission timer after sending a test packet that includes the Access Report TLV. This timer MUST be disarmed upon reception of the reflected STAMP test packet that includes the Access Report TLV. In the event the timer expires before such a packet is received, the Session-Sender MUST retransmit the STAMP test packet that contains the Access Report TLV. This retransmission SHOULD be repeated up to four times before the procedure is aborted. Setting the value for the retransmission timer is based on local policies and the network environment. The default value of the retransmission timer for the Access Report TLV SHOULD be three seconds. An implementation MUST provide control of the retransmission timer value and the number of retransmissions.
セッション送信者は、アクセスレポートTLVを含むテストパケットを送信した後に再送信タイマーをアームする必要があります。このタイマーは、アクセスレポートTLVを含む反射スタンプテストパケットの受信時に解除されなければなりません。このようなパケットが受信される前にタイマーが期限切れになると、セッション送信者はアクセスレポートTLVを含むスタンプテストパケットを再送信する必要があります。この再送信は、手順が中止される前に最大4回繰り返されるべきです。再送タイマーの値を設定することは、ローカルポリシーとネットワーク環境に基づいています。アクセスレポートTLVの再送信タイマのデフォルト値は3秒にする必要があります。実装は、再送信タイマ値と再送信数を制御する必要があります。
The Access Report TLV is used by the Performance Measurement Function (PMF) components of the Access Steering, Switching, and Splitting feature for 5G networks [TS23501]. The PMF component in the User Equipment acts as the STAMP Session-Sender, and the PMF component in the User Plane Function acts as the STAMP Session-Reflector.
アクセスレポートTLVは、5Gネットワーシングのアクセス操作、スイッチング、および分割機能の性能測定機能（PMF）成分[TS23501]で使用されます。ユーザー機器のPMFコンポーネントはスタンプセッション送信者として機能し、ユーザープレーン機能のPMFコンポーネントはスタンプセッションリフレクタとして機能します。
A Session-Reflector might be able to put only an "SW Local" (see Table 9) timestamp in the Follow-Up Timestamp field. But the hosting system might provide a timestamp closer to the start of the actual packet transmission even though it is not possible to deliver the information to the Session-Sender in time for the packet itself. This timestamp might nevertheless be important for the Session-Sender, as it improves the accuracy of network delay measurement by minimizing the impact of egress queuing delays on the measurement.
セッションリフレクタは、フォローアップタイムスタンプフィールドの「SWローカル」（表9を参照）のタイムスタンプだけを入れることができます。しかし、ホスティングシステムは、パケット自体の間に情報を間に合わせることができなくても、実際のパケット送信の開始に近いタイムスタンプを提供することができる。それにもかかわらず、このタイムスタンプは、測定に対する出力キューイング遅延の影響を最小限に抑えることによってネットワーク遅延測定の精度を向上させるので、セッション送信者にとって重要であるかもしれません。
A STAMP Session-Sender MAY include the Follow-Up Telemetry TLV to request information from the Session-Reflector. The Session-Sender MUST set the Follow-Up Telemetry Type and Length fields to their appropriate values. The Sequence Number and Follow-Up Timestamp fields MUST be zeroed on transmission by the Session-Sender and ignored by the Session-Reflector upon receipt of the STAMP test packet that includes the Follow-Up Telemetry TLV. The Session-Reflector MUST validate the Length value of the STAMP test packet. If the value of the Length field is invalid, the Session-Reflector MUST zero the Sequence Number and Follow-Up Timestamp fields and set the M flag in the STAMP TLV Flags field in the reflected packet. If the Session-Reflector is in the stateless mode (defined in Section 4.2 of [RFC8762]), it MUST zero the Sequence Number and Follow-Up Timestamp fields.
スタンプセッション送信者は、セッションリフレクタから情報を要求するためのフォローアップテレメトリTLVを含み得る。セッション送信者は、フォローアップテレメトリの種類と長さのフィールドを適切な値に設定する必要があります。シーケンス番号およびフォローアップタイムスタンプフィールドは、セッション送信側による送信時にゼロ化され、フォローアップテレメトリTLVを含むスタンプテストパケットを受信したときにセッションリフレクタによって無視されなければなりません。セッションリフレクタはスタンプテストパケットの長さ値を検証する必要があります。長さフィールドの値が無効な場合、セッションリフレクタはシーケンス番号とフォローアップタイムスタンプフィールドをゼロにする必要があり、反射パケットの[スタンプTLVフラグ]フィールドにMフラグを設定する必要があります。セッションリフレクタがステートレスモード（RFC8762のセクション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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Follow-Up Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Follow-Up Telemetry TLV
図15：フォローアップテレメトリTLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 7 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値7はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field, set equal to the value 16 octets.
長さ：2オクテットフィールドは、値16オクテットに等しく設定されています。
Sequence Number: A four-octet field indicating the sequence number of the last packet reflected in the same STAMP test session. Since the Session-Reflector runs in the stateful mode (defined in Section 4.2 of [RFC8762]), it is the Session-Reflector's Sequence Number of the previous reflected packet.
シーケンス番号：同じスタンプテストセッションに反映された最後のパケットのシーケンス番号を示す4オクテットフィールド。セッションリフレクタはステートフルモードで実行されているので（RFC8762のセクション4.2で定義）、以前の反射パケットのセッションリフレクタのシーケンス番号です。
Follow-Up Timestamp: An eight-octet field, with the format indicated by the Z flag of the Error Estimate field of the STAMP base packet, which is contained in this reflected test packet transmitted by a Session-Reflector, as described in Section 4.2.1 of [RFC8762]. It carries the timestamp when the reflected packet with the specified sequence number was sent.
フォローアップタイムスタンプ：セッションリフレクタによって記述されたこの反射テストパケットに含まれるスタンプベースパケットの誤差推定フィールドのzフラグによって示されたフォーマットの8オクテットフィールド。.1 [RFC8762]。指定されたシーケンス番号の反射パケットが送信されたときにタイムスタンプを搭載しています。
Timestamp M(ode): A one-octet field that characterizes the method by which the entity that transmits a reflected STAMP packet obtained the Follow-Up Timestamp. Table 9 lists the possible values.
TimesTamp M（ODE）：フォローアップタイムスタンプを取得した反射スタンプパケットを送信するエンティティがその方法を特徴付ける1オクテットフィールド。表9に可能な値を示します。
Reserved: A three-octet field. Its value MUST be zeroed on transmission and ignored on receipt.
予約済み：3オクテットフィールド。その値は送信時にゼロにされ、受信時に無視されなければなりません。
The STAMP authenticated mode protects the integrity of data collected in the STAMP base packet. STAMP extensions are designed to provide valuable information about the condition of a network, and protecting the integrity of that data is also essential. All authenticated STAMP base packets (per Sections 4.2.2 and 4.3.2 of [RFC8762]) compatible with this specification MUST additionally authenticate the optional TLVs by including the keyed Hashed Message Authentication Code (HMAC) TLV, with the sole exception of when there is only one TLV present and it is the Extended Padding TLV. The HMAC TLV MUST follow all TLVs included in a STAMP test packet except for the Extra Padding TLV. If the HMAC TLV appears in any other position in a STAMP extended test packet, then the situation MUST be processed as HMAC verification failure, as defined below in this section. The HMAC TLV MAY be used to protect the integrity of STAMP extensions in the STAMP unauthenticated mode. An implementation of STAMP extensions MUST provide controls to enable the integrity protection of STAMP extensions in the STAMP unauthenticated mode.
スタンプ認証モードは、スタンプベースパケットに収集されたデータの整合性を保護します。スタンプ拡張は、ネットワークの状態に関する貴重な情報を提供し、そのデータの完全性を保護するように設計されています。この仕様と互換性のある認証されたすべてのスタンプベースパケット（[RFC8762]および[RFC8762]の[RFC8762]および4.3.2）は、キー入力されたハッシュメッセージ認証コード（HMAC）TLVを含むことによってオプションのTLVを認証する必要があります。存在するTLVは1つだけであり、それは拡張パディングTLVです。 HMAC TLVは、余分なパディングTLVを除いてスタンプテストパケットに含まれているすべてのTLVに従わなければなりません。 HMAC TLVがスタンプ拡張テストパケット内の他の位置に現れる場合は、このセクションでは、次のようにHMAC検証失敗として処理する必要があります。 HMAC TLVは、スタンプ認証モードでスタンプ拡張の完全性を保護するために使用されてもよい。スタンプ拡張機能の実装は、スタンプ認証モードでスタンプ拡張の完全性保護を可能にするためのコントロールを提供する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: HMAC TLV
図16：HMAC TLV
The fields are defined as follows:
フィールドは次のように定義されています。
STAMP TLV Flags: An eight-bit field. Its format is presented in Figure 6.
スタンプTLVフラグ：8ビットフィールド。そのフォーマットは図6に示されています。
Type: A one-octet field. Value 8 has been allocated by IANA (Section 5.1).
タイプ：1オクテットフィールド。値8はIANAによって割り当てられています（セクション5.1）。
Length: A two-octet field, set equal to the value 16 octets.
長さ：2オクテットフィールドは、値16オクテットに等しく設定されています。
HMAC: A 16-octet field that carries the HMAC digest of the text of all preceding TLVs.
HMAC：前のすべてのTLVのテキストのHMACダイジェストを搭載した16オクテットフィールド。
As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 bits (see [RFC4868]). All considerations regarding using the key listed in Section 4.4 of [RFC8762] are fully applicable to the use of the HMAC TLV. Key management and the mechanisms to distribute the HMAC key are outside the scope of this specification. The HMAC TLV is anticipated to track updates in the base STAMP protocol [RFC8762], including the use of more advanced cryptographic algorithms. HMAC is calculated as defined in [RFC2104] over text as the concatenation of the Sequence Number field of the base STAMP packet and all preceding TLVs. The digest then MUST be truncated to 128 bits and written into the HMAC field. If the HMAC TLV is present in the extended STAMP test packet, e.g., in the authenticated mode, HMAC MUST be verified before using any data in the included STAMP TLVs. If HMAC verification by the Session-Reflector fails, then the Session-Reflector MUST stop processing the received extended STAMP test packet. The Session-Reflector MUST copy the TLVs from the received STAMP test packet into the reflected packet. The Session-Reflector MUST set the I flag in each TLV copied over into the reflected packet to 1 before transmitting the reflected test packet. If the Session-Sender receives the extended STAMP test packet with I flag set to 1, then the Session-Sender MUST stop processing TLVs in the reflected test packet. If HMAC verification by the Session-Sender fails, then the Session-Sender MUST stop processing TLVs in the reflected extended STAMP packet.
[RFC8762]で定義されているように、スタンプはHMAC-SHA-256を使用して128ビットに切り捨てられます（[RFC4868]参照）。 [RFC8762]のセクション4.4に記載されているキーを使用することに関するすべての考慮事項は、HMAC TLVの使用に完全に適用されます。 HMACキーを配布するためのキー管理とメカニズムは、この仕様の範囲外です。 HMAC TLVは、より高度な暗号化アルゴリズムの使用を含む、ベーススタンププロトコル[RFC8762]の更新を追跡する予定です。 HMACは、テキスト上で[RFC2104]で定義されているとおり、ベーススタンプパケットのシーケンス番号フィールドと前のTLVのすべてのTLVの連結として計算されます。次にダイジェストは128ビットに切り捨てられ、HMACフィールドに書き込まれなければなりません。 HMAC TLVが拡張スタンプテストパケット内に存在する場合、例えば認証モードでは、含まれているスタンプTLVのデータを使用する前にHMACを検証する必要があります。セッションリフレクタによるHMAC検証が失敗した場合、セッションリフレクタは受信した拡張スタンプテストパケットの処理を停止する必要があります。セッションリフレクタは、受信したスタンプテストパケットからのTLVを反射パケットにコピーする必要があります。セッションリフレクタは、反射されたテストパケットを送信する前に、各TLV内のIフラグを反射パケットにコピーされた各TLVに設定しなければならない。セッション送信者がIフラグを1に設定して拡張スタンプテストパケットを受信した場合、セッション送信者は反射テストパケット内のTLVの処理を停止する必要があります。セッション送信者によるHMAC検証が失敗した場合、セッション送信者は反射拡張スタンプパケット内のTLVの処理を停止する必要があります。
IANA has created the following subregistries under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry.
IANAは、「シンプルな双方向アクティブ測定プロトコル（スタンプ）TLVタイプ」レジストリの下に、次のサブレジストリを作成しました。
IANA has created the "STAMP TLV Types" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 1.
IANAは「スタンプTLVタイプ」サブレジストを作成しました。このレジストリのコードポイントは、表1に記載されている登録手順[RFC8126]に従って割り当てられます。
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 175 | IETF Review |
+-----------+-------------------------+
| 176 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 251 | Experimental Use |
+-----------+-------------------------+
| 252 - 254 | Private Use |
+-----------+-------------------------+
Table 1: Registration Procedures for the STAMP TLV Types Subregistry
表1：スタンプTLVタイプサブレジストの登録手順
Per this document, IANA has allocated the following values in the "STAMP TLV Types" subregistry:
この文書ごとに、IANAは「スタンプTLV型」サブリストに以下の値を割り当てました。
+=======+=======================+===========+
| Value | Description | Reference |
+=======+=======================+===========+
| 0 | Reserved | RFC 8972 |
+-------+-----------------------+-----------+
| 1 | Extra Padding | RFC 8972 |
+-------+-----------------------+-----------+
| 2 | Location | RFC 8972 |
+-------+-----------------------+-----------+
| 3 | Timestamp Information | RFC 8972 |
+-------+-----------------------+-----------+
| 4 | Class of Service | RFC 8972 |
+-------+-----------------------+-----------+
| 5 | Direct Measurement | RFC 8972 |
+-------+-----------------------+-----------+
| 6 | Access Report | RFC 8972 |
+-------+-----------------------+-----------+
| 7 | Follow-Up Telemetry | RFC 8972 |
+-------+-----------------------+-----------+
| 8 | HMAC | RFC 8972 |
+-------+-----------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+-----------------------+-----------+
Table 2: STAMP TLV Types
表2：スタンプTLV型
IANA has created the "STAMP TLV Flags" subregistry. The registration procedure is "IETF Review" [RFC8126]. The flags are 8 bits. Per this document, IANA has allocated the following bit positions in the "STAMP TLV Flags" subregistry.
IANAは「スタンプTLVフラグ」サブレイストを作成しました。登録手順は「IETFレビュー」[RFC8126]です。フラグは8ビットです。この文書ごとに、IANAは「スタンプTLVフラグ」サブレイストに次のビット位置を割り当てました。
+==============+========+========================+===========+
| Bit position | Symbol | Description | Reference |
+==============+========+========================+===========+
| 0 | U | Unrecognized TLV | RFC 8972 |
+--------------+--------+------------------------+-----------+
| 1 | M | Malformed TLV | RFC 8972 |
+--------------+--------+------------------------+-----------+
| 2 | I | Integrity check failed | RFC 8972 |
+--------------+--------+------------------------+-----------+
Table 3: STAMP TLV Flags
表3：スタンプTLVフラグ
IANA has created the "STAMP Sub-TLV Types" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 4.
IANAは「スタンプサブTLVタイプ」サブレイストを作成しました。このレジストリのコードポイントは、表4に記載されている登録手順[RFC8126]に従って割り当てられています。
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 175 | IETF Review |
+-----------+-------------------------+
| 176 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 251 | Experimental Use |
+-----------+-------------------------+
| 252 - 254 | Private Use |
+-----------+-------------------------+
Table 4: Registration Procedures for the STAMP Sub-TLV Types Subregistry
表4：スタンプサブTLVタイプサブレジストの登録手順
Per this document, IANA has allocated the following values in the "STAMP Sub-TLV Types" subregistry:
この文書ごとに、IANAは「Stamp Sub-TLV Types」サブレイストに次の値を割り当てました。
+=======+==========================+==========+===========+
| Value | Description | TLV Used | Reference |
+=======+==========================+==========+===========+
| 0 | Reserved | | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 1 | Source MAC Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 2 | Source EUI-48 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 3 | Source EUI-64 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 4 | Destination IP Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 5 | Destination IPv4 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 6 | Destination IPv6 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 7 | Source IP Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 8 | Source IPv4 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 9 | Source IPv6 Address | Location | RFC 8972 |
+-------+--------------------------+----------+-----------+
| 255 | Reserved | | RFC 8972 |
+-------+--------------------------+----------+-----------+
Table 5: STAMP Sub-TLV Types
表5：スタンプサブTLVタイプ
IANA has created the "STAMP Synchronization Sources" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 6.
IANAは「スタンプ同期ソース」サブレジストを作成しました。このレジストリのコードポイントは、表6に記載されている登録手順[RFC8126]に従って割り当てられています。
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 6: Registration Procedures for the STAMP Synchronization Sources Subregistry
表6：スタンプ同期ソースサブリジストリーの登録手順
Per this document, IANA has allocated the following values in the "STAMP Synchronization Sources" subregistry:
この文書ごとに、IANAは「スタンプ同期ソース」サブリストに次の値を割り当てました。
+=======+=================================+===========+
| Value | Description | Reference |
+=======+=================================+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------------------------+-----------+
| 1 | NTP | RFC 8972 |
+-------+---------------------------------+-----------+
| 2 | PTP | RFC 8972 |
+-------+---------------------------------+-----------+
| 3 | SSU/BITS | RFC 8972 |
+-------+---------------------------------+-----------+
| 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | RFC 8972 |
+-------+---------------------------------+-----------+
| 5 | Local free-running | RFC 8972 |
+-------+---------------------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------------------------+-----------+
Table 7: STAMP Synchronization Sources
表7：スタンプ同期ソース
IANA has created the "STAMP Timestamping Methods" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 8.
IANAは「スタンプタイムスタンピングメソッド」サブレジストを作成しました。このレジストリ内のコードポイントは、表8に記載されている登録手順[RFC8126]に従って割り当てられています。
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 8: Registration Procedures for the STAMP Timestamping Methods Subregistry
表8：スタンプタイムスタンピング方法の登録手順サブレジスト
Per this document, IANA has allocated the following values in the "STAMP Timestamping Methods" subregistry:
このドキュメントごとに、IANAは「スタンプタイムスタンプメソッド」サブレジストで次の値を割り当てました。
+=======+===============+===========+
| Value | Description | Reference |
+=======+===============+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------+-----------+
| 1 | HW Assist | RFC 8972 |
+-------+---------------+-----------+
| 2 | SW Local | RFC 8972 |
+-------+---------------+-----------+
| 3 | Control Plane | RFC 8972 |
+-------+---------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------+-----------+
Table 9: STAMP Timestamping Methods
表9：スタンプのタイムスタンプメソッド
IANA has created the "STAMP Return Codes" subregistry. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 10.
IANAは「スタンプ戻りコード」サブレイストを作成しました。このレジストリ内のコードポイントは、表10に記載されている登録手順[RFC8126]に従って割り当てられます。
+===========+=========================+
| Range | Registration Procedures |
+===========+=========================+
| 1 - 127 | IETF Review |
+-----------+-------------------------+
| 128 - 239 | First Come First Served |
+-----------+-------------------------+
| 240 - 249 | Experimental Use |
+-----------+-------------------------+
| 250 - 254 | Private Use |
+-----------+-------------------------+
Table 10: Registration Procedures for the STAMP Return Codes Subregistry
表10：スタンプリターンコードサブレジストの登録手順
Per this document, IANA has allocated the following values in the "STAMP Return Codes" subregistry:
この文書ごとに、IANAは「スタンプリターンコード」サブレジストに次の値を割り当てました。
+=======+=====================+===========+
| Value | Description | Reference |
+=======+=====================+===========+
| 0 | Reserved | RFC 8972 |
+-------+---------------------+-----------+
| 1 | Network available | RFC 8972 |
+-------+---------------------+-----------+
| 2 | Network unavailable | RFC 8972 |
+-------+---------------------+-----------+
| 255 | Reserved | RFC 8972 |
+-------+---------------------+-----------+
Table 11: STAMP Return Codes
表11：スタンプ戻りコード
This document defines extensions to STAMP [RFC8762] and inherits all the security considerations applicable to the base protocol. Additionally, the HMAC TLV is defined in this document. Though the HMAC TLV protects the integrity of STAMP extensions, it does not protect against a replay attack. The use of the HMAC TLV is discussed in detail in Section 4.8.
このドキュメントはスタンプ[RFC8762]の拡張子を定義し、基本プロトコルに適用されるすべてのセキュリティ上の考慮事項を継承します。さらに、HMAC TLVはこの文書で定義されています。HMAC TLVはスタンプ拡張の整合性を保護しますが、再生攻撃から保護されません。HMAC TLVの使用はセクション4.8で詳細に説明されています。
To protect against a malformed TLV, an implementation of a Session-Sender and Session-Reflector MUST:
不正な形式のTLVから保護するために、セッション送信者とセッションリフレクタの実装は次のことを行わなければなりません。
* check the setting of the M flag and
* Mフラグの設定を確認してください
* validate the Length field value.
* 長さフィールド値を検証します。
As this specification defines the mechanism to test DSCP mapping, this document inherits all the security considerations discussed in [RFC2474]. Monitoring and optional control of DSCP using the CoS TLV may be used across the Internet so that the Session-Sender and the Session-Reflector are located in domains that use different CoS profiles. Thus, it is essential that an operator verify the set of CoS values that is used in the Session-Reflector's domain. Also, an implementation of a Session-Reflector SHOULD support a local policy to confirm whether the value sent by the Session-Sender can be used as the value of the DSCP field. Section 4.4 defines the use of that local policy.
この仕様はDSCPマッピングをテストするメカニズムを定義するため、このドキュメントは[RFC2474]で説明したすべてのセキュリティ上の考慮事項を継承しています。COS TLVを使用したDSCPの監視とオプション制御は、セッション送信者とセッションリフレクタが異なるCOSプロファイルを使用するドメインに配置されるようにインターネット全体に使用できます。したがって、オペレータがセッションリフレクタのドメインで使用されるCOS値のセットを検証することが重要です。また、セッションリフレクタの実装は、セッション送信者によって送信された値をDSCPフィールドの値として使用できるかどうかを確認するためにローカルポリシーをサポートする必要があります。セクション4.4はそのローカルポリシーの使用を定義します。
[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"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.
[RFC8762] Mirsky、G.、G.、G.、G.、G.、Nydell、H.、およびR.FOTE、「シンプルな双方向アクティブ測定プロトコル」、RFC 8762、DOI 10.17487 / RFC8762、2020年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc8762>。
[GPS] "Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Standard", GPS SPS 5th Edition, April 2020.
[GPS]「全地球測位システム（GPS）標準測位サービス（SPS）性能スタンダード」、GPS SPS第5版、2020年4月。
[IEEE.1588.2008] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE.1588.2008] "ネットワーク測定システム用の精密クロック同期プロトコルのIEEE規格"、IEEE STD。2008年7月、DOI 10.1109 / IEEESTD.2008.4579760、<https://doi.org/10.1109/ieeeestd.2008.4579760>。
[NUM-IDS-GEN] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-06, 13 January 2021, <https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-06>.
[NUM-IDS-GEN] GONT、F.およびI。ARCE、「一時的な数値識別子の生成」、進行中の作業、インターネットドラフト、ドラフト - IRTF-Pearg-Numeric-IDS-Generation-06,13 1月13日2021、<https：//tools.ietf.org/html/draft -idtf-pearg-numeric -ids-generation-06>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[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] Kelly、S.およびS.Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびIPSecとHMAC-SHA-512を使用する」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<HTTPS：//www.rfc-editor.org/info/rfc4868>。
[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、「双方向アクティブ測定プロトコル（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]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[TS23501] 3GPP, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 16)", 3GPP TS 23.501, 2019.
[TS23501] 3GPP、「技術仕様グループサービスとシステムの側面; 5Gシステム（5GS）のシステムアーキテクチャ;ステージ2（リリース16） "、3GPP TS 23.501,2019。
Acknowledgments
謝辞
The authors very much appreciate the thorough review and thoughtful comments received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song, and Yali Wang. The authors express their gratitude to Al Morton for his comments and valuable suggestions. The authors greatly appreciate the comments and thoughtful suggestions received from Martin Duke.
著者らは、Tianran Zhou、Rakesh Gandhi、Yuezhong Song、Yali Wangから受け取った徹底的なレビューと思いやりのあるコメントをとても感謝しています。著者らは、彼のコメントや貴重な提案のためにAl Mortonに感謝を表明しています。著者らはMartin Dukeから受け取ったコメントや思慮深い提案に大きく感謝します。
Contributors
貢献者
The following individual contributed text to this document:
この文書への以下の個々の貢献されたテキスト：
Guo Jun ZTE Corporation 68# Zijinghua Road Nanjing Jiangsu, 210012 China
Guo Jun Zte Corporation 68＃Zijinghua Road南京江蘇省、210012中国
Phone: +86 18105183663
Email: guo.jun2@zte.com.cn
Authors' Addresses
著者の住所
Greg Mirsky ZTE Corp.
Greg Mirsky Zte Corp.
Email: gregimirsky@gmail.com
Xiao Min ZTE Corp.
Xiao Min Zte Corp.
Email: xiao.min2@zte.com.cn
Henrik Nydell Accedian Networks
ヘンリックナイデルアセディアンネットワーク
Email: hnydell@accedian.com
Richard Foote Nokia
Richard Foote Nokia.
Email: footer.foote@nokia.com
Adi Masputra Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America
ADI Masputra Apple Inc. 1アップアップルパークウェイCupertino、CA 95014アメリカ合衆国
Email: adi@apple.com
Ernesto Ruffini OutSys via Caracciolo, 65 20155 Milan Italy
アーネストRuffini Outsys via caracciolo、65 20155ミラノイタリア
Email: eruffini@outsys.org