[要約] RFC 8972は、双方向能動測定プロトコル「STAMP」の機能を強化するための、TLV形式によるオプション拡張仕様を規定しています。位置情報、詳細なタイムスタンプ、CoSマッピング、直接測定カウンタ、5G向けアクセスレポート、および整合性保護のためのHMAC等の多様なTLVを定義しています。複数のテストセッションを識別するための「SSID」を導入し、マルチベンダー環境における高度なネットワーク性能監視とトラブルシューティングを支援します。
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].
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はゼロでなければなりません
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 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.
STAMPセッションは、4タプル（送信元および宛先IPアドレス、送信元および宛先UDPポート番号）によって識別されます。STAMP Session-Senderは、ローカルで一意のSTAMPセッション識別子 (SSID) を生成してもよいです (MAY)。SSIDは、2オクテットのゼロ以外の符号なし整数です。SSID生成ポリシーは実装固有です。[NUM-IDS-GEN] では、識別子生成の一般的なアルゴリズムとその脆弱性を徹底的に分析しています。例えば、実装は [NUM-IDS-GEN] のセクション7.1に記載されているアルゴリズムを使用できます。実装は、異なるSTAMPテストセッションに同じ識別子を割り当ててはなりません (MUST NOT)。Session-Senderは、STAMPテストセッションを識別するためにSSIDを使用してもよいです (MAY)。SSIDが使用される場合、指定されたテストセッションの各テストパケットに存在しなければなりません (MUST)。非認証モードでは、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.
この仕様をサポートするSTAMP Session-Reflectorの実装は、セッションの通常の4タプルの要素と組み合わせてSSIDを使用してSTAMPセッションを識別しなければなりません (MUST)。テストセッションが開始される前に、Session-ReflectorはSTAMPセッションを識別するすべての要素でプロビジョニングされなければなりません (MUST)。STAMP Session-Reflectorは、一致しないSTAMPテストパケットを破棄しなければなりません (MUST)。STAMPセッション識別をプロビジョニングする手段は、この仕様の範囲外です。STAMP Session-Reflectorの適合実装は、図2に示すように、受信したテストパケットからSSID値をコピーし、それを反射パケットに入れなければなりません (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
この仕様をサポートしていないSTAMP Session-Reflectorは、反射されたSTAMPテストパケットでゼロクリアされたSSIDフィールドを返します。Session-Senderは、ゼロクリアされたSSIDフィールドを受信した場合、セッションを停止してもよいです (MAY)。Session-Senderの実装は、そのようなシナリオにおける自身の動作の制御をサポートしなければなりません (MUST)。テストセッションが停止されない場合、Session-Senderは、例えばベースSTAMPパケット [RFC8762] を送信したり、SSIDを含むSTAMPテストパケットの送信を継続したりすることができます。
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はSTAMPテストパケット内のオプションフィールドです。STAMPテストパケットには複数のTLVを配置してもよいです (MAY)。問題の（外側）TLVのセマンティクスを条件として、特定のTLV内に追加のTLVを囲んでもよいです。TLVには、1オクテットのSTAMP TLV Flagsフィールド、1オクテットのTypeフィールド、およびオクテット単位のValueフィールドの長さに等しい2オクテットのLengthフィールドがあります。TLVまたはsub-TLVのType値がPrivate Use [RFC8126] の範囲にある場合、長さは少なくとも4でなければならず (MUST)、最初の4オクテットは、ネットワークオクテット順で、IANAの「SMI Network Management Private Enterprise Codes」サブレジストリに記録されている当該ベンダーのStructure of Management Information (SMI) Private Enterprise Codeでなければなりません (MUST)。Valueフィールドの残りはベンダーにプライベートです。以下のセクションでは、基本仕様を超えてSTAMP機能を拡張するSTAMP用の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 (Unrecognized): 1ビットのフラグ。Session-Senderは、拡張STAMPテストパケットを送信する前にUフラグを0に設定しなければなりません。Session-Reflectorは、TLVを理解しなかった場合にUフラグを1に設定しなければなりません (MUST)。それ以外の場合、Session-Reflectorは反射パケット内のUフラグを0に設定しなければなりません (MUST)。
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 (Malformed): 1ビットのフラグ。Session-Senderは、拡張STAMPテストパケットを送信する前にMフラグを0に設定しなければなりません (MUST)。Session-Reflectorは、TLVが不正であると判断した場合（すなわち、特定のタイプに対してLengthフィールド値が有効でない、または拡張STAMPパケットの残り長がTLVのサイズより小さい場合）、Mフラグを1に設定しなければなりません (MUST)。それ以外の場合、Session-Reflectorは反射パケット内のMフラグを0に設定しなければなりません (MUST)。
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 (Integrity): 1ビットのフラグ。Session-Senderは、拡張STAMPテストパケットを送信する前にIフラグを0に設定しなければなりません (MUST)。STAMP拡張がHMAC検証に失敗した場合（セクション4.8）、Session-ReflectorはIフラグを1に設定しなければなりません (MUST)。それ以外の場合、Session-Reflectorは反射パケット内のIフラグを0に設定しなければなりません (MUST)。
R: Reserved flags for future use. These flags MUST be zeroed on transmit and ignored on receipt.
R: 将来の使用のための予約フラグ。これらのフラグは、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Session-SenderであれSession-Reflectorであれ、テストパケットを受信したSTAMPノードは、そのパケットがベースSTAMPパケットであるか、または1つ以上のTLVを含んでいるかを判断しなければなりません (MUST)。ノードは、特定のSTAMPテストセッションの設定に基づいて、UDPヘッダーのLengthフィールドの値と、非認証または認証モードにおけるベースSTAMPテストパケットの長さとを比較しなければなりません (MUST)。2つの値の差がUDPヘッダーの長さより大きい場合、テストパケットにはベースSTAMPテストパケットの直後に続く1つ以上のSTAMP TLVが含まれています。STAMP拡張をサポートしていないSession-Reflectorは、[RFC8762] のセクション4.3で定義されているように、それらを処理せずに反射パケットにコピーします。TLVをサポートするSession-Reflectorは、それらのTLV内のUフラグを1に設定することによって、処理しなかった特定のTLVを示します。
A STAMP Session-Sender that has received a reflected STAMP test packet with extension TLVs MUST validate each TLV:
拡張TLVを含む反射STAMPテストパケットを受信したSTAMP Session-Senderは、各TLVを検証しなければなりません (MUST)。
* If the U flag is set, the STAMP system MUST skip the processing of the TLV.
* Uフラグが設定されている場合、STAMPシステムはTLVの処理をスキップしなければなりません (MUST)。
* If the M flag is set, the STAMP system MUST stop processing the remainder of the extended STAMP packet.
* Mフラグが設定されている場合、STAMPシステムは拡張STAMPパケットの残りの処理を停止しなければなりません (MUST)。
* 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フラグが設定されている場合、STAMPシステムはすべてのTLVを破棄しなければならず (MUST)、拡張STAMPパケットの残りの処理を停止しなければなりません (MUST)。
* 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.
* Session-Reflectorの実装がTypeフィールドの値を認識しない場合、反射STAMPパケットにTLVのコピーを含めなければなりません (MUST)。Session-ReflectorはUフラグを1に設定しなければなりません (MUST)。Session-Reflectorは認識されないTLVの処理をスキップしなければなりません (MUST)。
* 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の処理を停止しなければなりません (MUST)。Session-Reflectorは、受信した拡張STAMPパケットの残りを反射STAMPパケットにコピーしなければなりません (MUST)。Session-ReflectorはMフラグを1に設定しなければなりません (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
Extra Padding: このフィールドは、一連の擬似乱数で埋めるべきです (SHOULD)。このフィールドはすべてゼロで埋めてもよいです (MAY)。実装は、Extra Paddingフィールドの内容を制御しなければなりません (MUST)。
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.
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.
STAMP Session-Senderは、Session-Reflectorから位置情報を照会するために可変サイズの位置TLVを含めてもよいです (MAY)。Session-Senderは、STAMP TLV Flags、Type、およびLengthフィールドを除き、いかなる情報フィールドも入力してはなりません (MUST NOT)。Session-Reflectorは、TLVが整形式であることを検証しなければなりません (MUST)。そうでない場合、Session-Reflectorは不正な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で定義されたとおりです。Iフラグは、送信前にSession-SenderおよびSession-Reflectorによって0に設定されなければならず (MUST)、受信時にその値は無視されます。Location TLVに対する以下のタイプのsub-TLVが本書で定義されています（表5にType値を示します）。
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.
Source MAC Address sub-TLV: 12オクテットのsub-TLVです。Type値は1です。Lengthフィールドの値は8に等しくなければなりません (MUST)。Valueフィールドは8オクテットのMBZフィールドであり、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Destination MAC Address sub-TLV: 12オクテットのsub-TLVです。Type値は2です。Lengthフィールドの値は8に等しくなければなりません (MUST)。Valueフィールドは8オクテットの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Source IPv4 Address sub-TLV: 8オクテットのsub-TLVです。Type値は5です。Lengthフィールドの値は4に等しくなければなりません (MUST)。Valueフィールドは4オクテットのMBZフィールドであり、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Destination IPv4 Address sub-TLV: 8オクテットのsub-TLVです。Type値は6です。Lengthフィールドの値は4に等しくなければなりません (MUST)。Valueフィールドは4オクテットのMBZフィールドであり、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Destination IPv4 Address sub-TLV: IPv4の宛先アドレスを含む20オクテットのsub-TLV。Typeの値は5です。Lengthフィールドの値は16に等しくなければなりません (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Source IPv6 Address sub-TLV: 20オクテットのsub-TLVです。Type値は7です。Lengthフィールドの値は16に等しくなければなりません (MUST)。Valueフィールドは16オクテットのMBZフィールドであり、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Destination IPv6 Address sub-TLV: 20オクテットのsub-TLVです。Type値は8です。Lengthフィールドの値は16に等しくなければなりません (MUST)。Valueフィールドは16オクテットのMBZフィールドであり、送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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):
Source IPv4 Address sub-TLV: IPv4の送信元アドレスを含む20オクテットのsub-TLV。Typeの値は8です。Lengthフィールドの値は16に等しくなければなりません (MUST)。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オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Source IPv6 Address sub-TLV: IPv6の送信元アドレスを含む20オクテットのsub-TLV。Typeの値は9です。Lengthフィールドの値は16に等しくなければなりません (MUST)。Valueフィールドは16オクテットのIPv6 Addressフィールドです。
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.
Session-Senderは、Location TLV内にDestination MAC Address sub-TLVを含めてもよいです (MAY)。Session-ReflectorがDestination MAC Address sub-TLVを含むLocation TLVを受信した場合、受信した拡張テストパケットの宛先MACアドレスがEUI-48形式であれば、Destination EUI-48 Address sub-TLVを含めなければなりません (MUST)。そしてSession-Reflectorは、宛先MACアドレスの値をEUI-48フィールドにコピーしなければなりません (MUST)。そうでない場合、Session-ReflectorはDestination EUI-64 Address sub-TLVを使用しなければならず (MUST)、受信したパケットの宛先MACアドレスの値をEUI-64フィールドにコピーしなければなりません (MUST)。受信した拡張STAMPテストパケットに宛先MACアドレスがない場合、Session-Reflectorは反射パケットを送信する前にEUI-64フィールドをゼロクリアしなければなりません (MUST)。
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.
Session-Senderは、Location TLV内にSource MAC Address sub-TLVを含めてもよいです (MAY)。Session-ReflectorがSource MAC Address sub-TLVを含むLocation TLVを受信した場合、受信した拡張テストパケットの送信元MACアドレスがEUI-48形式であれば、Source EUI-48 Address sub-TLVを含めなければなりません (MUST)。そしてSession-Reflectorは、送信元MACアドレスの値をEUI-48フィールドにコピーしなければなりません (MUST)。そうでない場合、Session-ReflectorはSource EUI-64 Address sub-TLVを使用しなければならず (MUST)、受信したパケットの送信元MACアドレスの値をEUI-64フィールドにコピーしなければなりません (MUST)。受信した拡張STAMPテストパケットに送信元MACアドレスがない場合、Session-Reflectorは反射パケットを送信する前にEUI-64フィールドをゼロクリアしなければなりません (MUST)。
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.
Session-Senderは、Location TLV内にDestination IP Address sub-TLVを含めてもよいです (MAY)。Session-ReflectorがDestination IP Address sub-TLVを含むLocation TLVを受信した場合、受信した拡張テストパケットの送信元IPアドレスがIPv4アドレスファミリであれば、Destination IPv4 Address sub-TLVを含めなければなりません (MUST)。そしてSession-Reflectorは、宛先IPアドレスの値をIPv4 Addressフィールドにコピーしなければなりません (MUST)。そうでない場合、Session-ReflectorはDestination IPv6 Address sub-TLVを使用しなければならず (MUST)、受信したパケットの宛先IPアドレスの値をIPv6 Addressフィールドにコピーしなければなりません (MUST)。
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.
Session-Senderは、Location TLV内にSource IP Address sub-TLVを含めてもよいです (MAY)。Session-ReflectorがSource IP Address sub-TLVを含むLocation TLVを受信した場合、受信した拡張テストパケットの送信元IPアドレスがIPv4アドレスファミリであれば、Source IPv4 Address sub-TLVを含めなければなりません (MUST)。そしてSession-Reflectorは、送信元IPアドレスの値をIPv4 Addressフィールドにコピーしなければなりません (MUST)。そうでない場合、Session-ReflectorはSource IPv6 Address sub-TLVを使用しなければならず (MUST)、受信したパケットの送信元IPアドレスの値をIPv6 Addressフィールドにコピーしなければなりません (MUST)。
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.
Location TLVは、STAMPパケットのラストホップIPアドレス、ポート、およびラストホップMACアドレスを決定するために使用してもよいです (MAY)。MACアドレスは、ラストホップでのパス切り替えを示すことができます。IPアドレスとUDPポートは、パス上にNATルータが存在するかどうかを示します。これにより、Session-SenderはNATの背後にあるSession-ReflectorのIPアドレスを特定し、STAMPパケットが誤ったSession-Reflectorに送信される原因となり得る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.
STAMP Session-Senderは、Session-Reflectorから情報を要求するためにTimestamp Information TLVを含めてもよいです (MAY)。Session-Senderは、STAMP TLV Flags、Type、およびLengthを除き、いかなる情報フィールドも入力してはなりません (MUST NOT)。他のすべてのフィールドはゼロで埋められなければなりません (MUST)。Session-Reflectorは、TLVのLength値を検証しなければなりません (MUST)。Lengthフィールドの値が無効な場合、Session-Reflectorは不正な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.
STAMP Session-Senderは、STAMPテストパケット内にClass of Service (CoS) TLVを含めてもよいです (MAY)。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 (Reverse Path): 2ビットのフィールドです。Session-Senderは、送信時にRPフィールドの値を0に設定しなければなりません (MUST)。
Reserved: A 16-bit field that MUST be zeroed on transmission and ignored on receipt.
Reserved: 送信時にゼロクリアされ、受信時に無視されなければならない (MUST) 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を含むテストパケットを受信したSTAMPのSession-Reflectorは、反射するテストパケットにCoS TLVを含めなければなりません (MUST)。また、Session-Reflectorは、受信したSTAMPテストパケットのIPヘッダのDSCPフィールドとECNフィールドの値を、反射するテストパケットのDSCP2フィールドにコピーしなければなりません (MUST)。最後に、Session-Reflectorは、DSCP1フィールドの値に対応するCoSがそのドメインで許可されているかどうかを、ローカルポリシーを使って検証しなければなりません (MUST)。許可されている場合、Session-Reflectorは、反射するテストパケットのIPヘッダのDSCPフィールドの値を、受信したテストパケットのDSCP1フィールドの値と等しく設定しなければなりません (MUST)。そうでない場合、Session-Reflectorは、受信したSTAMPパケットのDSCP値を使用し、RPフィールドの値を1に設定しなければなりません (MUST)。反射されたパケットを受信したとき、RPフィールドの値が0であれば、Session-Senderは逆方向のCoSの分析のためにDSCPとECNの値を保存します。受信した反射パケットの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.
Length: 2オクテットのフィールドです。Lengthフィールドの値は4に等しくなければなりません (MUST)。
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.
MBZ: 2オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Session-Reflector Rx counter (R_RxC): 4オクテットのフィールド。送信時にSession-Senderによって0にされ、受信時にSession-Reflectorによって無視されなければなりません (MUST)。Session-Reflectorは、受信したインプロファイルのパケットの値でこれを埋めなければなりません (MUST)。
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.
Session-Reflector Tx counter (R_TxC): 4オクテットのフィールド。Session-Senderによって0にされ、受信時にSession-Reflectorによって無視されなければなりません (MUST)。Session-Reflectorは、送信したインプロファイルのパケットの値でこれを埋めなければなりません (MUST)。
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.
STAMPテストパケットには、Direct Measurement TLVが最大2つ存在してもよいです (MAY)。Direct Measurement TLVがSTAMPテストパケットに存在する場合、セクション4.8で定義されているように、直後にHMAC TLVが続かなければなりません (MUST)。
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.
STAMPのSession-Senderは、アクセスネットワークの状態の変化をSession-Reflectorに示すために、Access Report TLV（図14）を含めてもよいです (MAY)。アクセスネットワークの定義は本文書の範囲外です。
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.
MBZ: 12オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
Resv: A four-bit field that MUST be zeroed on transmission and ignored on receipt.
MBZ: 12オクテットのフィールドです。送信時にゼロクリアされ、受信時に無視されなければなりません (MUST)。
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.
Length: 2オクテットのフィールドです。Lengthフィールドの値は8に等しくなければなりません (MUST)。
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.
Access Report TLVを含めるSTAMPのSession-Senderは、報告するアクセスネットワークの種類に応じてAccess IDフィールドの値を設定します。また、Session-Senderは、アクセスネットワークの運用状態を反映するようにReturn Codeフィールドの値を設定します。アクセスネットワークの状態を判断する仕組みは本仕様の範囲外です。Access Report TLVを含むテストパケットを受信したSTAMPのSession-Reflectorは、反射するテストパケットにAccess Report TLVを含めなければなりません (MUST)。Session-Reflectorは、Access IDフィールドとReturn Codeフィールドの値を、受信したテストパケットの対応するフィールドの値と等しく設定しなければなりません (MUST)。
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.
Session-Senderは、Access Report TLVを含むテストパケットを送信した後、再送タイマーも起動しなければなりません (MUST)。このタイマーは、Access Report TLVを含む反射されたSTAMPテストパケットを受信した時点で停止されなければなりません (MUST)。そのようなパケットを受信する前にタイマーが満了した場合、Session-Senderは、Access Report TLVを含むSTAMPテストパケットを再送しなければなりません (MUST)。この再送は、手順を中止するまでに最大4回繰り返すべきです (SHOULD)。再送タイマーの値の設定は、ローカルポリシーとネットワーク環境に基づきます。Access Report TLVの再送タイマーのデフォルト値は3秒とすべきです (SHOULD)。実装は、再送タイマーの値と再送回数を制御する手段を提供しなければなりません (MUST)。
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.
STAMP Session-Senderは、反射パケットの送信元ポート番号の変更を制御するためにSource Port sub-TLVを含めてもよいです (MAY)。Session-Reflectorは、受信したテストパケットのSource Port sub-TLVに示されたポート番号を、反射パケットの送信元ポート番号として使用しなければなりません (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
Length: 2オクテットのフィールドです。Lengthフィールドの値は16に等しくなければなりません (MUST)。
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.
STAMP認証モードは、STAMPベースパケットに収集されたデータの完全性を保護します。STAMP拡張はネットワークの状態に関する貴重な情報を提供するため、そのデータの完全性を保護するように設計されています。この仕様に準拠するすべての認証済みSTAMPベースパケット（[RFC8762] のセクション4.2.2および4.3.2）は、鍵付きHash Message Authentication Code (HMAC) TLVを含めることによってオプションのTLVを認証しなければなりません (MUST)。ただし、存在するTLVが1つだけであり、それがExtra Padding TLVである場合は除きます。HMAC TLVは、Extra Padding TLVを除き、STAMPテストパケットに含まれるすべてのTLVの後になければなりません (MUST)。HMAC TLVがSTAMP拡張テストパケット内の他の位置に現れた場合、本セクションで後述するようにHMAC検証失敗として処理しなければなりません (MUST)。HMAC TLVは、STAMP非認証モードでSTAMP拡張の完全性を保護するために使用してもよいです (MAY)。STAMP拡張の実装は、STAMP非認証モードでSTAMP拡張の完全性保護を有効にするための制御を提供しなければなりません (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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] で定義されているように、STAMPは128ビットに切り捨てられたHMAC-SHA-256を使用します（[RFC4868] を参照）。[RFC8762] のセクション4.4に記載されている鍵の使用に関するすべての考慮事項は、HMAC TLVの使用に完全に適用されます。鍵管理およびHMAC鍵を配布するメカニズムは、この仕様の範囲外です。HMAC TLVは、より高度な暗号アルゴリズムの使用を含め、ベースSTAMPプロトコル [RFC8762] の更新に追従することが期待されています。HMACは、[RFC2104] で定義されているように、ベースSTAMPパケットのSequence Numberフィールドと先行するすべてのTLVの連結としてのテキストに対して計算されます。その後、ダイジェストは128ビットに切り捨てられ、HMACフィールドに書き込まれなければなりません (MUST)。HMAC TLVが拡張STAMPテストパケットに存在する場合（例えば認証モードにおいて）、含まれるSTAMP TLV内のデータを使用する前にHMACを検証しなければなりません (MUST)。Session-ReflectorによるHMAC検証が失敗した場合、Session-Reflectorは受信した拡張STAMPテストパケットの処理を停止しなければなりません (MUST)。Session-Reflectorは、受信したSTAMPテストパケットからのTLVを反射パケットにコピーしなければなりません (MUST)。Session-Reflectorは、反射テストパケットを送信する前に、反射パケットにコピーされた各TLV内のIフラグを1に設定しなければなりません (MUST)。Session-SenderがIフラグが1に設定された拡張STAMPテストパケットを受信した場合、Session-Senderは反射テストパケット内のTLVの処理を停止しなければなりません (MUST)。Session-SenderによるHMAC検証が失敗した場合、Session-Senderは反射拡張STAMPパケット内のTLVの処理を停止しなければなりません (MUST)。
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から保護するために、Session-SenderおよびSession-Reflectorの実装は以下のことを行わなければなりません (MUST)。
* 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の監視および任意の制御は、Session-SenderとSession-Reflectorが異なるCoSプロファイルを使用するドメインに配置されるようにインターネット全体で使用される可能性があります。したがって、運用者がSession-Reflectorのドメインで使用されるCoS値のセットを検証することが不可欠です。また、Session-Reflectorの実装は、Session-Senderによって送信された値をDSCPフィールドの値として使用できるかどうかを確認するためのローカルポリシーをサポートすべきです (SHOULD)。セクション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., and R. Canetti, "HMAC：メッセージ認証用keyed-hashing"、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.、「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] Cotton, M., Leiba, B., and 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., Jun, G., Nydell, H., and R. Foote、「シンプルな双方向アクティブ測定プロトコル」、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/IEEESTD.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. and I. Arce、「一時的な数値識別子の生成」、進行中の作業、インターネットドラフト、ドラフト - IRTF-Pearg-Numeric-IDS-Generation-06,13 1月13日2021、<https://tools.ietf.org/html/draft-irtf-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., and D. Black、「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. and 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., and 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] Mills, D., Martin, J., Ed., Burbank, J., and 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, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 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