[要約] RFC 10052は、簡易双方向アクティブ測定プロトコル（STAMP）に、Session-Reflectorが受信パケットと異なる長さや数の反射テストパケットを返せるようにする任意の拡張として、Reflected Test Packet Control TLVを定義する標準化過程の文書です。Session-Senderは、反射パケットの長さ、個数、送信間隔をこのTLVで要求でき、Session-Reflectorは反射レートと総量に上限を設けて輻輳を防ぎます。あわせてマルチキャスト環境での測定の課題を分析し、Layer 2 Address Group sub-TLVとLayer 3 Address Group sub-TLVで応答するSession-Reflectorを絞り込む方法や、DoS攻撃対策などのセキュリティ上の考慮事項を示します。
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 10052 Ciena Corporation
Category: Standards Track E. Ruffini
ISSN: 2070-1721 OutSys
H. Nydell
Cisco Systems
R. Foote
Nokia
W. Hawkins
University of Cincinnati
September 2026
This document defines an optional extension to the Simple Two-way Active Measurement Protocol (STAMP) that enables a Session-Reflector to send asymmetrical packets, that is, response packets whose size or quantity differs from those sent by the Session-Sender. While standard STAMP exchanges are symmetrical, certain measurement scenarios benefit from reflected packets of different lengths or additional responses to better approximate application traffic conditions. The extension specifies the Reflected Test Packet Control TLV and associated procedures, analyzes challenges in active performance measurement (including in multicast environments), and describes STAMP behaviors to improve measurement efficiency and reduce network impact.
本文書は、簡易双方向アクティブ測定プロトコル (STAMP) に対する任意の拡張を定義します。この拡張により、Session-Reflector は非対称パケット、すなわち Session-Sender が送信したパケットとはサイズまたは数が異なる応答パケットを送信できるようになります。標準的な STAMP の交換は対称ですが、測定シナリオによっては、長さの異なる反射パケットや追加の応答を用いることで、アプリケーションのトラフィック条件をより良く近似できます。この拡張は、Reflected Test Packet Control TLV と関連する手順を規定し、(マルチキャスト環境を含む) アクティブな性能測定における課題を分析し、測定効率を向上させてネットワークへの影響を低減するための STAMP の動作を説明します。
This is an Internet Standards Track document.
これは Internet Standards Track 文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティのコンセンサスを表しています。本文書は公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認されました。Internet Standards についての詳細は 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/rfc10052.
本文書の現在のステータス、正誤表、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc10052 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および本文書の著者として特定された人々。All rights reserved.
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
本文書は、BCP 78 および本文書の公開日時点で有効な IETF Trust の IETF 文書に関する法的規定 (https://trustee.ietf.org/license-info) の適用を受けます。これらの文書は本文書に関するあなたの権利と制限を記述しているため、注意深く確認してください。本文書から抽出されたコードコンポーネントには、Trust Legal Provisions のセクション 4.e に記載されている Revised BSD License のテキストを含めなければならず、Revised BSD License に記載されているとおり無保証で提供されます。
1. Introduction 2. Conventions Used in This Document 2.1. Terminology 2.2. Acronyms 2.3. Requirements Language 3. Reflected Test Packet Control TLV 3.1. Address Group Sub-TLVs 3.1.1. Layer 2 Address Group Sub-TLV 3.1.2. Layer 3 Address Group Sub-TLV 4. Operational Considerations 4.1. Rate Measurement 4.1.1. Operational Considerations for Performing Rate Measurement 4.2. Active Performance Measurement in a Multicast Environment 4.3. Using Reflected Test Packet Control TLV in Combination with Other TLVs 5. Security Considerations 6. IANA Considerations 6.1. Reflected Test Packet Control TLV Type 6.2. Conformant Reflected Packet STAMP TLV Flag 6.3. Layer 2 and Layer 3 Address Group Sub-TLV Types 7. References 7.1. Normative References 7.2. Informative References Acknowledgments Authors' Addresses
The Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defines the base STAMP functionalities. STAMP Optional Extensions [RFC8972] introduces a TLV structure that allows a Session-Sender to include optional instructions for Session-Reflectors to extend the functionality of the base STAMP protocol. New STAMP TLVs can be defined to support scenarios like the ones described in [RFC7497], which discusses the coordination of messaging between the source and destination to help deliver one of the fundamental principles of IP performance metric measurements, minimizing the test traffic effect on user flows.
簡易双方向アクティブ測定プロトコル (STAMP) [RFC8762] は、STAMP の基本機能を定義しています。STAMP Optional Extensions [RFC8972] は TLV 構造を導入しており、Session-Sender が Session-Reflector に対して任意の指示を含めることで、基本 STAMP プロトコルの機能を拡張できます。[RFC7497] に述べられているようなシナリオをサポートするために、新しい STAMP TLV を定義できます。[RFC7497] は、IP 性能メトリック測定の基本原則の一つである、テストトラフィックがユーザーフローに与える影響の最小化を実現するための、送信元と宛先の間のメッセージ交換の調整について論じています。
By default, a STAMP Session-Sender and a Session-Reflector exchange packets symmetrically: The number of packets sent by the Session-Reflector and the Session-Sender are the same, and the length of the packets sent by the Session-Reflector and the Session-Sender are the same. However, in some scenarios, e.g., rate measurements discussed in [RFC7497], it would be beneficial for a Session-Reflector to respond with asymmetrical test packets: packets whose length is not symmetrical to the test packet sent by the Session-Sender and/or packets that are not sent in direct response to a packet received from a Session-Sender. The optional extension defined in this document gives operators the tools to create such asymmetrical packets between a Session-Sender and a Session-Reflector.
既定では、STAMP の Session-Sender と Session-Reflector はパケットを対称的に交換します。つまり、Session-Reflector と Session-Sender が送信するパケットの数は同じであり、Session-Reflector と Session-Sender が送信するパケットの長さも同じです。しかし、[RFC7497] で論じられているレート測定のようなシナリオでは、Session-Reflector が非対称なテストパケットで応答することが有益な場合があります。非対称なテストパケットとは、Session-Sender が送信したテストパケットと長さが対称ではないパケット、および/または Session-Sender から受信したパケットへの直接の応答として送信されないパケットです。本文書で定義する任意の拡張は、Session-Sender と Session-Reflector の間でそのような非対称パケットを作成するための手段をオペレーターに提供します。
Measurement of performance metrics in a multicast network using an active measurement method (Section 3.4 of [RFC7799]) has specific challenges compared to what operators experience monitoring in a unicast network. This document analyzes these challenges and specifies procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.
アクティブ測定方式 ([RFC7799] のセクション 3.4) を用いたマルチキャストネットワークでの性能メトリックの測定には、オペレーターがユニキャストネットワークの監視で経験するものと比べて、特有の課題があります。本文書はこれらの課題を分析し、ネットワークへの影響をより小さくしてより効率的な測定を実現するための手順と STAMP 拡張を規定します。
This document uses terms defined in [RFC8762], specifically Session-Sender, Session-Reflector, and symmetrical packets.
本文書は [RFC8762] で定義された用語、具体的には Session-Sender、Session-Reflector、および対称パケットを使用します。
This document uses terms defined in [RFC8972], specifically STAMP Session Identifier (SSID), STAMP TLV Flags, and Sub-TLVs.
本文書は [RFC8972] で定義された用語、具体的には STAMP Session Identifier (SSID)、STAMP TLV Flags、および Sub-TLV を使用します。
This document uses terms defined in [RFC7497], specifically In-Service and Out-of-Service.
本文書は [RFC7497] で定義された用語、具体的にはインサービス (In-Service) とアウトオブサービス (Out-of-Service) を使用します。
In this document, "asymmetrical packets" has two meanings, depending on the context. The first aspect is asymmetry in packet size between a packet sent by a Session-Reflector and the packet it received from the Session-Sender. The second aspect is asymmetry in the number of packets the Session-Reflector transmits in response to receiving a single STAMP-Test packet.
本文書では、「非対称パケット」は文脈に応じて2つの意味を持ちます。1つ目は、Session-Reflector が送信するパケットと、Session-Sender から受信したパケットとの間のパケットサイズの非対称性です。2つ目は、単一の STAMP-Test パケットを受信したことに応答して Session-Reflector が送信するパケットの数の非対称性です。
In this document, a multicast network means a communication network model where a sender transmits a single packet addressed to a multicast group, and the network delivers copies of that packet to multiple receivers that have joined the group.
本文書では、マルチキャストネットワークとは、送信者がマルチキャストグループ宛ての単一のパケットを送信し、ネットワークがそのパケットのコピーを、そのグループに参加している複数の受信者に配送する通信ネットワークモデルを意味します。
CE:
CE:
Congestion Experienced
Congestion Experienced (輻輳経験)
ECN:
ECN:
Explicit Congestion Notification
Explicit Congestion Notification (明示的輻輳通知)
EUI:
EUI:
Extended Unique Identifier
Extended Unique Identifier (拡張一意識別子)
MAC:
MAC:
Media Access Control
Media Access Control (メディアアクセス制御)
STAMP:
STAMP:
Simple Two-way Active Measurement Protocol
簡易双方向アクティブ測定プロトコル
TLV:
TLV:
Type-Length-Value
Type-Length-Value (タイプ・長さ・値)
This section defines an additional optional STAMP extension, the Reflected Test Packet Control TLV, and an additional bit flag in the STAMP TLV Flags field. The format of this TLV is presented in Figure 1.
本セクションでは、追加の任意の STAMP 拡張である Reflected Test Packet Control TLV と、STAMP TLV Flags フィールド内の追加のビットフラグを定義します。この TLV の形式を図 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Length of the Reflected Packet |Number of the Reflected Packets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval Between the Reflected Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reflected Test Packet Control TLV Format
図 1: Reflected Test Packet Control TLV の形式
The descriptions of the fields are as follows:
各フィールドの説明は次のとおりです。
STAMP TLV Flags:
STAMP TLV Flags:
Type:
Type:
A one-octet field that identifies the Reflected Test Packet Control TLV. This field is set to 12 (Section 6.1).
Reflected Test Packet Control TLV を識別する1オクテットのフィールドです。このフィールドは 12 に設定されます (セクション 6.1)。
Length:
Length:
A two-octet field. The value is variable and MUST NOT be smaller than 12 octets.
2オクテットのフィールドです。値は可変であり、12オクテットより小さくしてはなりません (MUST NOT)。
Length of the Reflected Packet:
Length of the Reflected Packet:
A two-octet field. The value is an unsigned integer that is the requested length of a reflected test packet in octets.
2オクテットのフィールドです。値は符号なし整数で、要求される反射テストパケットの長さをオクテット単位で表します。
Number of the Reflected Packets:
Number of the Reflected Packets:
A two-octet field. The value is an unsigned integer that is the number of reflected test packets that the Session-Reflector is requested to transmit in response to receiving a STAMP-Test packet with the Reflected Test Packet Control TLV.
2オクテットのフィールドです。値は符号なし整数で、Reflected Test Packet Control TLV を含む STAMP-Test パケットを受信した際に、Session-Reflector が送信するよう要求される反射テストパケットの数を表します。
Interval Between the Reflected Packets:
Interval Between the Reflected Packets:
A four-octet field. The value is an unsigned integer set to the interval in nanoseconds between the transmission of the consecutive reflected test packets in response to receiving a STAMP-Test packet with the Reflected Test Packet Control TLV.
4オクテットのフィールドです。値は符号なし整数で、Reflected Test Packet Control TLV を含む STAMP-Test パケットを受信した際に送信される、連続する反射テストパケット間の送信間隔をナノ秒単位で設定します。
Sub-TLVs:
Sub-TLVs:
An optional field that includes additional information communicated by a Session-Sender.
Session-Sender が伝達する追加情報を含む、オプションのフィールドです。
Also, an additional STAMP TLV flag [RFC8972], the Conformant Reflected Packet, has been allocated by IANA in the "STAMP TLV Flags" registry (Section 6.2): the one-bit C flag (3). A Session-Sender MUST zero this flag on transmission, and the Session-Reflector MUST ignore its value on the receipt of a STAMP-Test packet with a STAMP TLV.
また、追加の STAMP TLV フラグ [RFC8972] である Conformant Reflected Packet が、IANA により "STAMP TLV Flags" レジストリ (6.2節) に割り当てられています。これは1ビットの C flag (3) です。Session-Sender は送信時にこのフラグをゼロにしなければならず (MUST)、Session-Reflector は STAMP TLV を伴う STAMP-Test パケットの受信時にその値を無視しなければなりません (MUST)。
A Session-Sender MAY include the Reflected Test Packet Control TLV in a STAMP test packet. If the received STAMP-Test packet includes the Reflected Test Packet Control TLV, the Session-Reflector MUST transmit a sequence of reflected test packets according to the following rules:
Session-Sender は、STAMP テストパケットに Reflected Test Packet Control TLV を含めてもよい (MAY)。受信した STAMP-Test パケットに Reflected Test Packet Control TLV が含まれている場合、Session-Reflector は次の規則に従って反射テストパケットの列を送信しなければなりません (MUST)。
* The length of the reflected test packet MUST be the largest of:
* 反射テストパケットの長さは、次のうち最大のものでなければなりません (MUST):
a. The length of a base Session-Reflector packet in the mode (unauthenticated or authenticated) of the received STAMP-Test packet, as defined in Section 4.3 of [RFC8762], including all STAMP extension TLVs [RFC8972] present in the received STAMP-Test packet but excluding any Extra Padding TLVs. The rationale to exclude any Extra Padding TLVs present in combination with the Reflected Test Packet Control TLV is to support a scenario in which a Session-Reflector is requested to transmit a sequence of packets shorter than the received STAMP packet.
a. 受信した STAMP-Test パケットのモード (認証なしまたは認証あり) における、[RFC8762] の4.3節で定義されたベース Session-Reflector パケットの長さ。受信した STAMP-Test パケットに存在するすべての STAMP 拡張 TLV [RFC8972] を含み、Extra Padding TLV は除きます。Reflected Test Packet Control TLV と併存する Extra Padding TLV を除外する根拠は、Session-Reflector が、受信した STAMP パケットより短いパケット列を送信するよう要求されるシナリオをサポートするためです。
b. The value in the Length of the Reflected Packet field of the Reflected Test Packet Control TLV aligned at a four-octet boundary.
b. Reflected Test Packet Control TLV の Length of the Reflected Packet フィールドの値を、4オクテット境界に整列させたもの。
In a case where the length of the reflected packet calculated by this rule is longer than the length of the reflected packet calculated by the rules in Section 4 of [RFC8972], the Session-Reflector MUST use the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the length of the reflected test packet. If the calculated length of the reflected packet exceeds the maximum transmission unit (MTU) of the interface to reach the Session-Sender, the Session-Reflector MUST set the Conformant Reflected Packet STAMP TLV flag (Section 6.2) to 1 and MUST transmit a single reflected packet of the length equal to the MTU of the egress interface. Otherwise, the Session-Reflector MUST set the C flag to 0 in each reflected test packet.
この規則で計算された反射パケットの長さが、[RFC8972] の4節の規則で計算された反射パケットの長さより長い場合、Session-Reflector は、反射テストパケットの長さを増やすために Extra Padding TLV ([RFC8972] の4.1節) を使用しなければなりません (MUST)。計算された反射パケットの長さが、Session-Sender に到達するためのインタフェースの最大伝送単位 (MTU) を超える場合、Session-Reflector は Conformant Reflected Packet STAMP TLV フラグ (6.2節) を1に設定しなければならず (MUST)、出力インタフェースの MTU に等しい長さの反射パケットを1つだけ送信しなければなりません (MUST)。それ以外の場合、Session-Reflector は各反射テストパケットで C flag を0に設定しなければなりません (MUST)。
The number of reflected test packets in the sequence MUST equal the value of the Number of the Reflected Packets field.
列に含まれる反射テストパケットの数は、Number of the Reflected Packets フィールドの値に等しくなければなりません (MUST)。
If the value of the Number of the Reflected Packets field is greater than 1, the interval between the transmission of two consecutive reflected packets in the sequence MUST be equal to the value in the Interval Between the Reflected Packets field in nanoseconds. To prevent excessive congestion caused by reflected packets, a Session-Reflector that supports the Reflected Test Packet Control TLV MUST enforce limits on both the data rate (bytes per second) and the total data volume (bytes) of the STAMP payload it generates in response to an incoming test packet. If a test packet is received that would generate traffic that exceeds either of these limits, the Session-Reflector MUST set the C flag (Section 6.2) to 1 and MUST transmit a single reflected packet of the length calculated by the rules listed above. Otherwise, the Session-Reflector MUST set the C flag to 0 in each reflected test packet.
Number of the Reflected Packets フィールドの値が1より大きい場合、列内の連続する2つの反射パケットの送信間隔は、Interval Between the Reflected Packets フィールドの値 (ナノ秒) に等しくなければなりません (MUST)。反射パケットによる過度の輻輳を防ぐため、Reflected Test Packet Control TLV をサポートする Session-Reflector は、受信したテストパケットに応答して生成する STAMP ペイロードについて、データレート (バイト毎秒) と総データ量 (バイト) の両方に制限を適用しなければなりません (MUST)。いずれかの制限を超えるトラフィックを生成することになるテストパケットを受信した場合、Session-Reflector は C flag (6.2節) を1に設定しなければならず (MUST)、上記の規則で計算された長さの反射パケットを1つだけ送信しなければなりません (MUST)。それ以外の場合、Session-Reflector は各反射テストパケットで C flag を0に設定しなければなりません (MUST)。
If the Number of the Reflected Packets field is set to 0, the Session-Reflector MUST NOT send any reflected packets. Furthermore, in this case, the Session-Reflector SHOULD discard the received STAMP-Test packet. However, a local policy MAY override this default behavior and specify an alternative handling. Note that this behavior of the Session-Reflector is demonstrated when the Control Code Flags field of the Return Path Control Code sub-TLV (Section 4.1.1 of [RFC9503]) is set to No Reply Requested. If this is the intended behavior, use of the Return Path TLV is preferable.
Number of the Reflected Packets フィールドが0に設定されている場合、Session-Reflector は反射パケットを一切送信してはなりません (MUST NOT)。さらにこの場合、Session-Reflector は受信した STAMP-Test パケットを破棄すべきです (SHOULD)。ただし、ローカルポリシーによってこのデフォルトの動作を上書きし、別の処理を指定してもよい (MAY)。なお、この Session-Reflector の動作は、Return Path Control Code sub-TLV ([RFC9503] の4.1.1節) の Control Code Flags フィールドが No Reply Requested に設定されている場合にも示されます。これが意図する動作である場合は、Return Path TLV の使用が望ましいです。
Each reflected test packet in the sequence is formed according to Section 4.3 of [RFC8762].
列内の各反射テストパケットは、[RFC8762] の4.3節に従って構成されます。
As defined above, there are two cases when a Session-Reflector will set the C flag in the reflected packet. To disambiguate which case led to the C flag being set to 1, an implementation of a Session-Sender can determine the cause as follows:
上記で定義したとおり、Session-Reflector が反射パケットに C flag を設定する場合は2通りあります。どちらの場合が C flag を1にしたのかを区別するため、Session-Sender の実装は、次のようにして原因を判定できます。
* If the length of the received reflected STAMP packet is less than the value of the Length of the Reflected Packet field, the requested length exceeds the MTU of the egress interface of the Session-Reflector.
* 受信した反射 STAMP パケットの長さが Length of the Reflected Packet フィールドの値より小さい場合、要求された長さが Session-Reflector の出力インタフェースの MTU を超えています。
* If the length of the received reflected STAMP packet equals the value of the Length of the Reflected Packet field, the requested data rate and/or the data volume exceed the limits set at the Session-Reflector.
* 受信した反射 STAMP パケットの長さが Length of the Reflected Packet フィールドの値に等しい場合、要求されたデータレートまたはデータ量 (あるいはその両方) が、Session-Reflector に設定された制限を超えています。
A multicast network that uses an active performance measurement method for In-Service rate estimation MUST include a rate control mechanism that bounds and regulates the generation of measurement packets. Because multicast replication can amplify probe traffic across the distribution tree, uncontrolled probe emission risks introducing congestion, altering traffic asymmetry, or otherwise perturbing the conditions being measured. The rate control mechanism MUST ensure that probe traffic remains non-intrusive, predictable, and consistent with the operational characteristics of the multicast topology. Aligning probe generation behavior with the timing and packet selection semantics of the asymmetric packet measurement method makes it possible for observations collected at receivers to remain valid and comparable. To allow for deployment on networks with different characteristics (i.e., latency, throughput, etc.), implementations SHOULD provide operators with the ability to configure rate limits and pacing parameters that prevent excessive or uneven probe replication while still enabling statistically meaningful measurement samples.
インサービスのレート推定にアクティブ性能測定手法を用いるマルチキャストネットワークは、測定パケットの生成を制限し調整するレート制御メカニズムを含まなければなりません (MUST)。マルチキャストの複製は配送ツリー全体でプローブトラフィックを増幅しうるため、制御されないプローブの送出は、輻輳の発生、トラフィックの非対称性の変化、あるいは測定対象の条件への他の擾乱をもたらすおそれがあります。レート制御メカニズムは、プローブトラフィックが非侵入的で予測可能であり、マルチキャストトポロジの運用特性と整合した状態を保つことを保証しなければなりません (MUST)。プローブ生成の動作を、非対称パケット測定手法のタイミングおよびパケット選択のセマンティクスに合わせることで、受信側で収集される観測値の有効性と比較可能性を保てます。レイテンシやスループットなど特性の異なるネットワークに展開できるようにするため、実装は、統計的に有意な測定サンプルを得つつ、過度または不均一なプローブの複製を防ぐレート制限とペーシングパラメータを、オペレータが設定できるようにすべきです (SHOULD)。
An optional Layer 2 Address Group sub-TLV is a variable-length sub-TLV that includes a Layer 2 Address Group Mask and Address Group fields used by the Session-Sender to select the Session-Reflectors for a response. The Layer 2 Address Group sub-TLV can convey EUI-48 (Extended Unique Identifier), EUI-64 [IEEE-802.3-2022], and a 16-bit short address for local identification within a Personal Area Network [IEEE-802.15.4-2024]. The format of the Layer 2 Address Group sub-TLV is presented in Figure 2.
オプションの Layer 2 Address Group sub-TLV は可変長の sub-TLV で、Session-Sender が応答させる Session-Reflector を選択するために使用する Layer 2 Address Group Mask フィールドと Address Group フィールドを含みます。Layer 2 Address Group sub-TLV は、EUI-48 (Extended Unique Identifier)、EUI-64 [IEEE-802.3-2022]、およびパーソナルエリアネットワーク内のローカル識別用の16ビットショートアドレス [IEEE-802.15.4-2024] を伝達できます。Layer 2 Address Group sub-TLV の形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV Flags| Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Layer 2 Address Group Mask (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Layer 2 Address Group (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Layer 2 Address Group Sub-TLV Format
図2: Layer 2 Address Group Sub-TLV の形式
Where:
ここで:
Sub-TLV Flags:
Sub-TLV Flags:
An eight-bit field. The format, values, and interpretation of flags are as defined for STAMP TLV Flags [RFC8972]. Flag values are taken from the "STAMP TLV Flags" registry [IANA-STAMP].
8ビットのフィールドです。フラグの形式、値、および解釈は、STAMP TLV Flags [RFC8972] で定義されたとおりです。フラグの値は "STAMP TLV Flags" レジストリ [IANA-STAMP] から取られます。
Sub-TLV Type:
Sub-TLV Type:
A one-octet field. IANA has assigned value 10 (Section 6.3).
1オクテットのフィールドです。IANA は値10を割り当てました (6.3節)。
Sub-TLV Length:
Sub-TLV Length:
A two-octet field whose value equals the length of the Value field of the Layer 2 Address Group sub-TLV in octets. Because the lengths of the Layer 2 Address Group Mask and Layer 2 Address Group fields MUST be equal, valid values for the Sub-TLV Length are 4, 12, and 16. Any other value MUST be considered by the Session-Reflector as a malformed sub-TLV.
2オクテットのフィールドで、その値は Layer 2 Address Group sub-TLV の Value フィールドの長さ (オクテット単位) に等しくなります。Layer 2 Address Group Mask フィールドと Layer 2 Address Group フィールドの長さは等しくなければならない (MUST) ため、Sub-TLV Length の有効な値は 4、12、16 です。それ以外の値は、Session-Reflector により不正な形式の sub-TLV とみなされなければなりません (MUST)。
The Value field of the Layer 2 Address Group sub-TLV consists of the following fields:
Layer 2 Address Group sub-TLV の Value フィールドは、次のフィールドで構成されます。
Layer 2 Address Group Mask:
Layer 2 Address Group Mask:
A field that represents the bitmask to be applied to all MAC addresses associated with the Session-Reflector. The length of the field is 1/2 the value of the sub-TLV Length field.
Session-Reflector に関連付けられたすべての MAC アドレスに適用するビットマスクを表すフィールドです。このフィールドの長さは sub-TLV Length フィールドの値の1/2です。
Layer 2 Address Group:
Layer 2 Address Group:
A field that represents the group to which this TLV is addressed. The length of the field is 1/2 the value of the sub-TLV Length field.
この TLV の宛先となるグループを表すフィールドです。このフィールドの長さは sub-TLV Length フィールドの値の1/2です。
If the Session-Reflector applies the value of the Layer 2 Address Group Mask field (using a bitwise AND) to any of its MAC addresses with the same length and the result is equal to the value of the Layer 2 Address Group field, then the Session-Reflector MUST stop processing the Layer 2 Address Group sub-TLV and continue processing the received test packet. If no matches are found, the Session-Reflector MUST stop processing the received packet.
Session-Reflector が Layer 2 Address Group Mask フィールドの値を、同じ長さの自身の任意の MAC アドレスに（ビット単位の AND で）適用し、その結果が Layer 2 Address Group フィールドの値と等しい場合、Session-Reflector は Layer 2 Address Group sub-TLV の処理を停止し、受信したテストパケットの処理を続行しなければなりません (MUST)。一致するものが見つからない場合、Session-Reflector は受信したパケットの処理を停止しなければなりません (MUST)。
An optional Layer 3 Address Group sub-TLV is a variable-length sub-TLV that includes the IP Prefix and IP Prefix Length fields used by the Session-Sender to select the Session-Reflectors for a response. The format of the Layer 3 Address Group sub-TLV is presented in Figure 3.
任意の Layer 3 Address Group sub-TLV は可変長の sub-TLV であり、Session-Sender が応答を求める Session-Reflector を選択するために使用する IP Prefix フィールドと IP Prefix Length フィールドを含みます。Layer 3 Address Group sub-TLV の形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Layer 3 Address Group Sub-TLV Format
図3: Layer 3 Address Group Sub-TLV の形式
Where:
各項目の意味は次のとおりです。
Sub-TLV Flags:
Sub-TLV Flags:
An eight-bit field. The format, values, and interpretation of flags are as defined for STAMP TLV Flags [RFC8972]. Flag values are taken from the "STAMP TLV Flags" registry [IANA-STAMP].
8ビットのフィールドです。フラグの形式、値、および解釈は、STAMP TLV Flags [RFC8972] に定義されているとおりです。フラグの値は "STAMP TLV Flags" レジストリ [IANA-STAMP] から取得されます。
Sub-TLV Type:
Sub-TLV Type:
A one-octet field. IANA has assigned value 11 (Section 6.3).
1オクテットのフィールドです。IANA は値 11 を割り当てました (セクション6.3)。
Sub-TLV Length:
Sub-TLV Length:
A two-octet field whose value equals either 8 (if the IP Prefix is the prefix for an IPv4 address) or 20 (if the IP Prefix is the prefix for an IPv6 address). Any other value MUST be considered by the Session-Reflector as a malformed sub-TLV.
2オクテットのフィールドで、その値は 8 (IP Prefix が IPv4 アドレスのプレフィックスである場合) または 20 (IP Prefix が IPv6 アドレスのプレフィックスである場合) のいずれかに等しくなります。それ以外の値は、Session-Reflector によって不正な形式の sub-TLV とみなされなければなりません (MUST)。
The Value field of the Layer 3 Address Group sub-TLV consists of the following fields:
Layer 3 Address Group sub-TLV の Value フィールドは、次のフィールドで構成されます。
Prefix Length:
Prefix Length:
A one-octet unsigned integer field that contains the length, in bits, of the prefix of the value in the IP Prefix field.
IP Prefix フィールドの値のプレフィックスの長さをビット単位で格納する、1オクテットの符号なし整数フィールドです。
Reserved:
Reserved:
A three-octet field. The field MUST be zeroed on transmission and ignored on receipt.
3オクテットのフィールドです。このフィールドは、送信時にゼロにされ、受信時に無視されなければなりません (MUST)。
IP Prefix:
IP Prefix:
A variable-length field. The length of the field is four octets if the IP Prefix is the prefix for an IPv4 address or 16 if the IP Prefix is the prefix for an IPv6 address.
可変長のフィールドです。フィールドの長さは、IP Prefix が IPv4 アドレスのプレフィックスである場合は4オクテット、IPv6 アドレスのプレフィックスである場合は16オクテットです。
When processing this sub-TLV, the Session-Reflector will construct an IP mask according to the value, n, in the Prefix Length field. The IP mask will be an IP address (of the family specified by the value of the sub-TLV Length field, according to the semantics above) where the n most-significant bits are set to 1 and all other bits are set to 0. Once the mask is constructed, if the Session-Reflector applies it (using a bitwise AND) to any of its IP addresses of the same family and the result is equal to the value in the IP Prefix field, then the Session-Reflector MUST stop processing the Layer 3 Address Group sub-TLV and continue processing the received test packet. If no matches are found, the Session-Reflector MUST stop processing the received packet.
この sub-TLV を処理するとき、Session-Reflector は Prefix Length フィールドの値 n に従って IP マスクを構築します。IP マスクは、（上記の意味に従い、sub-TLV Length フィールドの値で指定されるアドレスファミリーの）IP アドレスであり、上位 n ビットが 1 に、その他のすべてのビットが 0 に設定されます。マスクの構築後、Session-Reflector がそれを同じファミリーの自身の任意の IP アドレスに（ビット単位の AND で）適用し、その結果が IP Prefix フィールドの値と等しい場合、Session-Reflector は Layer 3 Address Group sub-TLV の処理を停止し、受信したテストパケットの処理を続行しなければなりません (MUST)。一致するものが見つからない場合、Session-Reflector は受信したパケットの処理を停止しなければなりません (MUST)。
[RFC7497] defines the problem of access rate measurement in access networks. One of the essential requirements identified for a test protocol is the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. The Reflected Test Packet Control TLV, defined in Section 3, conforms to the requirements for measuring access rate by providing optional controls of the number of reflected test packets, the size of the reflected packet(s), and the time interval, i.e., rate, in transmitting the sequence of the reflected test packets. The access rate metric and method of access rate measurement are out of the scope of this document. The UDP Speed Test (see [RFC9097] and [RFC9946]) also allows for the measurement of access bandwidth.
[RFC7497] は、アクセスネットワークにおけるアクセスレート測定の問題を定義しています。テストプロトコルに求められる重要な要件の1つとして、テスト対象の経路上でパケットの特性（非対称なレートや非対称なパケットサイズなど）を制御できることが挙げられています。セクション3で定義した Reflected Test Packet Control TLV は、反射テストパケットの数、反射パケットのサイズ、および反射テストパケットの列を送信する際の時間間隔（すなわちレート）を任意で制御できるようにすることで、アクセスレート測定の要件に適合します。アクセスレートのメトリックおよびアクセスレート測定の方法は、本文書の対象範囲外です。UDP Speed Test ([RFC9097] および [RFC9946] を参照) でも、アクセス帯域幅を測定できます。
General considerations for using a testing protocol for rate measurement are documented in Section 7 of [RFC7497]. These considerations are specific for In-Service and Out-of-Service rate measurement. In the Out-of-Service testing, an operator may use a very high traffic rate and/or volume (i.e., high values for the Length of the Reflected Packet and/or Number of the Reflected Packets fields, and/or low values for the Interval Between the Reflected Packets field of the Reflected Test Packet Control TLV) to create congestion in the bottleneck. However, when performing In-Service rate testing, an operator may start with a low rate and/or volume and gradually increase them with each transmitted Reflected Test Packet Control TLV.
レート測定にテストプロトコルを使用する際の一般的な考慮事項は、[RFC7497] のセクション7に記載されています。これらの考慮事項は、インサービスおよびアウトオブサービスでのレート測定に固有のものです。アウトオブサービスのテストでは、オペレータは、ボトルネックで輻輳を発生させるために、非常に高いトラフィックレートや量（すなわち、Reflected Test Packet Control TLV の Length of the Reflected Packet フィールドや Number of the Reflected Packets フィールドの高い値、または Interval Between the Reflected Packets フィールドの低い値）を使用することがあります。一方、インサービスでのレートテストを行う場合、オペレータは低いレートや量から開始し、Reflected Test Packet Control TLV を送信するたびにそれらを徐々に増やすことがあります。
A service subscriber performing extensive rate measurements on the operational network SHOULD consider bullet item 6 in Section 11 of [RFC9946] and be mindful of limits placed on their service by the Service Provider. In particular, active measurement can lead to the generation of data volumes that may cause those performing the test to violate service-level agreements with their Service Provider.
運用ネットワーク上で大規模なレート測定を行うサービス加入者は、[RFC9946] のセクション11の箇条6を考慮すべきであり (SHOULD)、サービスプロバイダーによってサービスに課されている制限に留意すべきです。特に、アクティブ測定は大量のデータを生成する可能性があり、テストを実施する側がサービスプロバイダーとのサービスレベル契約に違反するおそれがあります。
For performance measurements using STAMP in a multicast environment, a Session-Sender is expected to be the root and Session-Reflectors are the leaves of the same multicast distribution tree. The mechanism of constructing the multicast tree is outside the scope of this document.
マルチキャスト環境で STAMP を使用して性能を測定する場合、Session-Sender は同一のマルチキャスト配送ツリーのルートであり、Session-Reflector はそのリーフであることが想定されます。マルチキャストツリーを構築する仕組みは、本文書の対象範囲外です。
According to [RFC8972], a STAMP Session is demultiplexed by a Session-Reflector by the tuple that consists of source and destination IP addresses, source and destination UDP port numbers, or the source IP address and STAMP Session Identifier. That is also the case when monitoring the performance of a multicast flow, despite the fact that the destination IP address is a multicast address. Therefore, there is no special behavior defined for a Session-Reflector upon receiving a STAMP-Test packet over a multicast tree. It processes the packet according to [RFC8762] and [RFC8972]. The Session-Reflector MUST use the source IP address of the received STAMP-Test packet as the destination IP address of the reflected test packet and MUST use one of the IP addresses associated with the node as the source IP address for that packet. As a result, a Session-Sender may receive multiple replies from multiple counterpart Session-Reflectors. Such a Session-Sender may include a Reflected Test Packet Control TLV and include either a Layer 2 Address Group sub-TLV or a Layer 3 Address Group sub-TLV to limit the Session-Reflectors that respond.
[RFC8972] によれば、STAMP セッションは、送信元および宛先の IP アドレスと送信元および宛先の UDP ポート番号からなるタプル、または送信元 IP アドレスと STAMP Session Identifier によって、Session-Reflector で多重分離されます。これは、宛先 IP アドレスがマルチキャストアドレスであっても、マルチキャストフローの性能を監視する場合にも当てはまります。したがって、マルチキャストツリー経由で STAMP-Test パケットを受信した Session-Reflector に対して、特別な動作は定義されていません。Session-Reflector は、[RFC8762] および [RFC8972] に従ってパケットを処理します。Session-Reflector は、受信した STAMP-Test パケットの送信元 IP アドレスを反射テストパケットの宛先 IP アドレスとして使用しなければならず (MUST)、そのノードに関連付けられた IP アドレスのいずれか1つをそのパケットの送信元 IP アドレスとして使用しなければなりません (MUST)。その結果、Session-Sender は、対応する複数の Session-Reflector から複数の応答を受信することがあります。このような Session-Sender は、応答する Session-Reflector を限定するために、Reflected Test Packet Control TLV を含め、さらに Layer 2 Address Group sub-TLV または Layer 3 Address Group sub-TLV のいずれかを含めることがあります。
The multicast environment itself could be configured to help alleviate the possibility that network congestion may occur if a single test packet generates a large number of concurrent replies, all directed to the same endpoint. Depending on the multicast implementation, adding the Reflected Test Packet Control TLV could allow the multicast environment to limit the number of replies by modifying the Reflected Test Packet Control TLV sub-TLV values of any STAMP packets it sees, allowing replies only from reflectors that are:
単一のテストパケットが多数の同時応答を生成し、そのすべてが同じエンドポイントに向けられた場合にネットワーク輻輳が発生する可能性を緩和できるよう、マルチキャスト環境自体を構成することもできます。マルチキャストの実装によっては、Reflected Test Packet Control TLV を追加することで、マルチキャスト環境が、目にした STAMP パケットの Reflected Test Packet Control TLV の sub-TLV の値を変更して応答数を制限し、次のようなリフレクターからのみ応答を許可できる場合があります。
* Randomly selected, by specifying a Layer 2 Address Group sub-TLV: for example, setting the EUI-48 Address Group Mask to 0xF and the EUI-48 Address Group to 0x1. As a result, only 1 out of 16 reflectors will reply;
* Layer 2 Address Group sub-TLV を指定することによりランダムに選択されたリフレクター。たとえば、EUI-48 Address Group Mask を 0xF に、EUI-48 Address Group を 0x1 に設定します。その結果、16台のリフレクターのうち1台だけが応答します。
* Hosted on a specific vendor Network Interface Card, by specifying a Layer 2 Address Group sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000; and
* EUI-48 Address Group Mask を 0xFFFFFF000000 に設定した Layer 2 Address Group sub-TLV を指定することにより選択された、特定のベンダーのネットワークインターフェースカード上でホストされているリフレクター。
* Belonging to specific IP networks, for example, a subnet dedicated to IPv6-over-IPv4 encapsulation, by specifying the appropriate Layer 3 Address Group sub-TLV.
* 適切な Layer 3 Address Group sub-TLV を指定することにより選択された、特定の IP ネットワーク（たとえば、IPv6-over-IPv4 カプセル化専用のサブネット）に属するリフレクター。
Multicast traffic is also intrinsically asymmetrical. The upstream (source-to-receiver) direction typically dominates, while the return path receives limited attention because multicast communication is primarily one-to-many and generates comparatively little downstream or receiver-to-source traffic. The value of the Length of the Reflected Packet field can be used to ensure that the reflected packet transports all the timestamps and requested information, which are crucial for the underlying measurement, but is as short as possible so as not to flood the network with useless data.
マルチキャストのトラフィックは、本質的に非対称でもあります。上り (送信元から受信者) 方向が通常は支配的であり、戻り経路はあまり注目されません。これは、マルチキャスト通信が主に1対多であり、下り方向、すなわち受信者から送信元へのトラフィックが比較的少ないためです。Length of the Reflected Packet フィールドの値を使用すると、反射パケットが、基礎となる測定に不可欠なすべてのタイムスタンプと要求された情報を運びつつ、無用なデータでネットワークをあふれさせないよう可能な限り短くなるようにできます。
[RFC9503] defines the Return Path TLV that, when used in combination with the Return Address Sub-TLV, allows a Session-Sender to request the reflected packet be sent to a different address from the Session-Sender one. These STAMP extensions could be used in combination with the Reflected Test Packet Control TLV, defined in this document, to direct the reflected STAMP-Test packets to a collector of measurement data (according to [RFC7594]) for further processing and network analytics. An example of the use case is a multicast scenario when, for example, the Session-Sender is close to the actual multicast source (such as a camera transmitting live video) so that the test packets follow the same path as the video stream packets in one direction but the reflected test packets follow another to a destination where the data would be analyzed.
[RFC9503] は Return Path TLV を定義しています。この TLV を Return Address Sub-TLV と組み合わせて使用すると、Session-Sender は、反射パケットを Session-Sender のアドレスとは異なるアドレスへ送信するよう要求できます。これらの STAMP 拡張を、本文書で定義する Reflected Test Packet Control TLV と組み合わせて使用することで、反射された STAMP-Test パケットを ([RFC7594] に従って) 測定データのコレクターへ誘導し、さらなる処理やネットワーク分析に供することができます。この用途の例として、マルチキャストのシナリオがあります。たとえば、Session-Sender が実際のマルチキャスト送信元 (ライブ映像を送信するカメラなど) の近くにあり、テストパケットが一方向ではビデオストリームのパケットと同じ経路をたどり、反射テストパケットはデータが分析される宛先へ別の経路をたどる場合です。
For compatibility with [RFC9503], a Session-Sender MUST NOT include a Return Path Control Code sub-TLV with the Control Code Flags set to No Reply Requested in a test packet that also contains a Reflected Test Packet Control TLV with a non-zero value. A Session-Reflector that supports both TLVs MUST set the U flag to 1 in both the Return Path and Reflected Test Packet Control TLVs within the reflected STAMP packet. Furthermore, the Session-Reflector SHOULD log a notification to inform an operator about the misconstructed STAMP packet.
[RFC9503] との互換性のため、Session-Sender は、ゼロ以外の値を持つ Reflected Test Packet Control TLV も含むテストパケットに、Control Code Flags を No Reply Requested に設定した Return Path Control Code sub-TLV を含めてはなりません (MUST NOT)。両方の TLV をサポートする Session-Reflector は、反射された STAMP パケット内の Return Path TLV と Reflected Test Packet Control TLV の両方で U フラグを 1 に設定しなければなりません (MUST)。さらに、Session-Reflector は、不正に構成された STAMP パケットについてオペレータに知らせるため、通知をログに記録すべきです (SHOULD)。
The Reflected Test Packet Control TLV can be combined with the Class of Service TLV [RFC8972] to augment rate testing or testing in a multicast network that monitors the consistency of Differentiated Services Code Point and ECN values in forward and reverse directions of the particular STAMP-Test session.
Reflected Test Packet Control TLV は、Class of Service TLV [RFC8972] と組み合わせることで、レートテストや、特定の STAMP-Test セッションの順方向と逆方向における Differentiated Services Code Point および ECN の値の一貫性を監視するマルチキャストネットワークでのテストを強化できます。
Security considerations discussed in [RFC7497], [RFC8762], [RFC8972], and [RFC9503] apply to this document. Furthermore, spoofed STAMP-Test packets with the Reflected Test Packet Control TLV can be exploited to conduct a Denial-of-Service (DoS) attack. Hence, implementations MUST use an identity protection mechanism. For example, the Session-Reflector may verify the information about the source of the STAMP packet against a pre-defined list of trusted nodes. Furthermore, an implementation that supports this specification MUST provide administrative control of support of the Reflected Test Packet Control TLV on a Session-Reflector with it being disabled by default. Also, either the STAMP authentication mode [RFC8762] or the HMAC (Hashed Message Authentication Code) TLV [RFC8972] SHOULD be used for a STAMP-Test session containing the Reflected Test Packet Control TLV. Note that if integrity protection is enabled, any in-path modification will cause verification to fail unless the modifying element is within the trust boundary and can recompute the integrity check.
[RFC7497]、[RFC8762]、[RFC8972]、および [RFC9503] で述べられているセキュリティ上の考慮事項は、本文書にも適用されます。さらに、Reflected Test Packet Control TLV を含む偽装された STAMP-Test パケットは、サービス拒否 (DoS) 攻撃の実行に悪用される可能性があります。したがって、実装はアイデンティティ保護の仕組みを使用しなければなりません (MUST)。たとえば、Session-Reflector は、STAMP パケットの送信元に関する情報を、事前に定義された信頼できるノードのリストと照合して検証することがあります。さらに、本仕様をサポートする実装は、Session-Reflector における Reflected Test Packet Control TLV のサポートを管理者が制御できるようにしなければならず (MUST)、デフォルトでは無効にしなければなりません。また、Reflected Test Packet Control TLV を含む STAMP-Test セッションには、STAMP 認証モード [RFC8762] または HMAC (Hashed Message Authentication Code) TLV [RFC8972] のいずれかを使用すべきです (SHOULD)。なお、完全性保護が有効な場合、経路上でのいかなる変更も検証の失敗を引き起こします。ただし、変更を行う要素が信頼境界内にあり、完全性チェックを再計算できる場合を除きます。
Furthermore, a DoS attack using the Reflected Test Packet Control TLV might target the STAMP Session-Reflector by overloading it with test packet reflection, e.g., minuscule intervals and/or an excessive number of concurrent test sessions. To mitigate that, a Session-Reflector implementation that supports the new TLV MUST provide a mechanism to limit the reflection rate and volume of STAMP-Test packets (see Section 3 for a detailed discussion).
さらに、Reflected Test Packet Control TLV を使用した DoS 攻撃は、極めて小さい間隔や過剰な数の同時テストセッションなどによってテストパケットの反射で過負荷にすることで、STAMP Session-Reflector を標的とする可能性があります。これを緩和するため、新しい TLV をサポートする Session-Reflector の実装は、STAMP-Test パケットの反射レートと量を制限する仕組みを提供しなければなりません (MUST) (詳細な議論についてはセクション3を参照)。
Considering the potential number of reflected packets generated by a single test packet sent to a multicast address, parameters in the first STAMP-Test packet with the Reflected Test Packet Control TLV MUST be selected conservatively. Consider the Number of the Reflected Packets field value set to one. As a result, a Session-Sender, by counting the packets reflected after originating a first STAMP-Test packet with the Reflected Test Packet Control TLV, can evaluate the load caused by using the Reflected Test Packet Control TLV in which more than a single reflected packet to the same multicast destination is requested. To further mitigate the risk of using the Reflected Test Packet Control TLV in a multicast network, a Session-Sender SHOULD sign packets using the HMAC TLV when sending such messages in unauthenticated mode [RFC8762]. But even with the HMAC TLV, the Reflected Test Packet Control TLV could be exploited by a replay attack. To mitigate that risk, a STAMP Session-Reflector SHOULD use the value of the Sequence Number field [RFC8762] of the received STAMP-Test packet. If that value compared to the received value in the previous test packet of the same STAMP-Test session is not monotonically increasing, then the Session-Reflector MUST respond with a single reflected packet, setting the U flag to 1 [RFC8972]. That may not indicate a replay attack, but there is packet re-ordering or packet duplication in the network. An operator can use other diagnostic methods to characterize and localize the problem. An implementation of the Session-Reflector can use the Serial Number Arithmetic [RFC1982] or any of the other methods to verify the correct ordering of test packets.
マルチキャストアドレスに送信された1つのテストパケットによって生成される反射パケット数の可能性を考慮して、Reflected Test Packet Control TLV を含む最初の STAMP-Test パケットのパラメータは、保守的に選択しなければなりません (MUST)。Number of the Reflected Packets フィールドの値を1に設定する場合を考えます。その結果、Session-Sender は、Reflected Test Packet Control TLV を含む最初の STAMP-Test パケットを送出した後に反射されたパケットを数えることで、同じマルチキャスト宛先に対して複数の反射パケットを要求する Reflected Test Packet Control TLV の使用によって生じる負荷を評価できます。マルチキャストネットワークで Reflected Test Packet Control TLV を使用するリスクをさらに緩和するために、Session-Sender は、非認証モード [RFC8762] でそのようなメッセージを送信する際、HMAC TLV を使用してパケットに署名すべきです (SHOULD)。しかし、HMAC TLV を使用しても、Reflected Test Packet Control TLV はリプレイ攻撃に悪用される可能性があります。そのリスクを緩和するために、STAMP Session-Reflector は、受信した STAMP-Test パケットの Sequence Number フィールド [RFC8762] の値を使用すべきです (SHOULD)。その値を、同じ STAMP-Test セッションの直前のテストパケットで受信した値と比較して単調増加でない場合、Session-Reflector は、U flag を1に設定して [RFC8972]、単一の反射パケットで応答しなければなりません (MUST)。これはリプレイ攻撃を示すとは限らず、ネットワーク内でパケットの順序入れ替わりまたは重複が発生していることを示す場合もあります。オペレーターは、他の診断方法を使用して問題の特徴づけと切り分けを行うことができます。Session-Reflector の実装は、テストパケットの正しい順序を検証するために、Serial Number Arithmetic [RFC1982] またはその他の任意の方法を使用できます。
A Session-Sender SHOULD NOT send the next STAMP-Test packet with the Reflected Test Packet Control TLV before the Session-Reflector is expected to complete the transmission of all reflected packets in response to the Reflected Test Packet Control TLV in the previous test packet. In some scenarios, the Reflected Test Packet Control TLV might induce congestion on the transient bottleneck. Section 10 of [RFC9097] specifies security requirements for capacity measurements with asymmetric UDP loads.
Session-Sender は、直前のテストパケットに含まれる Reflected Test Packet Control TLV に応答して Session-Reflector がすべての反射パケットの送信を完了すると見込まれる時点より前に、Reflected Test Packet Control TLV を含む次の STAMP-Test パケットを送信すべきではありません (SHOULD NOT)。一部のシナリオでは、Reflected Test Packet Control TLV が一時的なボトルネックで輻輳を引き起こす可能性があります。[RFC9097] のセクション10は、非対称 UDP 負荷による容量測定のセキュリティ要件を規定しています。
When planning In-Service capacity measurement, operators SHOULD follow recommendations formulated in Sections 3 and 7 of [RFC7497]. If the underlay network is ECN-capable, a Session-Reflector may receive STAMP-Test packets with the ECN field marked as Congestion Experienced (CE). ECN markings provide an indication of incipient congestion rather than packet loss. However, the interpretation of what constitutes "significant congestion" and the operational thresholds for reacting to ECN-CE depend on the specific deployment, service objectives, and operator policy. Operators should be aware that In-Service capacity measurements may influence congestion conditions, potentially contributing to ECN-CE marking in the network. Implementations and operational procedures SHOULD ensure that the use of STAMP for In-Service measurement does not unintentionally degrade data traffic or lead to misinterpretation of ECN-related congestion signals. Appropriate thresholds and mitigation actions remain deployment-specific and SHOULD be guided by operator policy and network performance objectives.
インサービスの容量測定を計画する際、オペレーターは [RFC7497] のセクション3および7に示された推奨事項に従うべきです (SHOULD)。アンダーレイネットワークが ECN に対応している場合、Session-Reflector は、ECN フィールドが Congestion Experienced (CE) とマークされた STAMP-Test パケットを受信することがあります。ECN マーキングは、パケット損失ではなく、輻輳の兆候を示すものです。ただし、何をもって「重大な輻輳」とみなすか、また ECN-CE に対処するための運用上のしきい値は、個々の展開環境、サービス目標、オペレーターのポリシーによって異なります。オペレーターは、インサービスの容量測定が輻輳の状況に影響を与え、ネットワーク内の ECN-CE マーキングの一因となる可能性があることに留意すべきです。実装および運用手順は、インサービス測定での STAMP の使用が、データトラフィックを意図せず劣化させたり、ECN に関連する輻輳シグナルの誤解を招いたりしないようにすべきです (SHOULD)。適切なしきい値と緩和措置は、引き続き展開環境ごとに固有であり、オペレーターのポリシーとネットワーク性能の目標に基づくべきです (SHOULD)。
Furthermore, Section 3.1.5 of [RFC8085] determines that a UDP congestion control SHOULD respond quickly to experienced congestion and account for loss rate and response time when choosing a new rate. And Section 8.1 of [RFC9097] specifies the load rate adjustment algorithm with its sample pseudocode offered in Appendix A of [RFC9097].
IANA has assigned a new value for the Reflected Test Packet Control TLV in the "STAMP TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group as follows:
IANAは、"Simple Two-way Active Measurement Protocol (STAMP) TLV Types" レジストリグループの "STAMP TLV Types" レジストリに、Reflected Test Packet Control TLV 用の新しい値を次のとおり割り当てました。
+=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 12 | Reflected Test Packet Control | RFC 10052 |
+-------+-------------------------------+-----------+
Table 1: Reflected Test Packet Control TLV Type
表1: Reflected Test Packet Control TLV Type
IANA has allocated a bit position for the Conformant Reflected Packet STAMP TLV flag in the "STAMP TLV Flags" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group as follows:
IANAは、"Simple Two-way Active Measurement Protocol (STAMP) TLV Types" レジストリグループの "STAMP TLV Flags" レジストリに、Conformant Reflected Packet STAMP TLV flag 用のビット位置を次のとおり割り当てました。
+==============+========+=============+===========+
| Bit position | Symbol | Description | Reference |
+==============+========+=============+===========+
| 3 | C | Conformant | RFC 10052 |
+--------------+--------+-------------+-----------+
Table 2: Conformant Reflected Packet STAMP TLV Flag
表2: Conformant Reflected Packet STAMP TLV Flag
IANA has assigned values for the Layer 2 Address Group and Layer 3 Address Group sub-TLV Types in the "STAMP Sub-TLV Types" registry under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry group as follows:
IANAは、"Simple Two-way Active Measurement Protocol (STAMP) TLV Types" レジストリグループの "STAMP Sub-TLV Types" レジストリに、Layer 2 Address Group および Layer 3 Address Group の Sub-TLV Types 用の値を次のとおり割り当てました。
+=======+=======================+================+===========+
| Value | Description | TLV Used | Reference |
+=======+=======================+================+===========+
| 10 | Layer 2 Address Group | Reflected Test | RFC 10052 |
| | | Packet Control | |
+-------+-----------------------+----------------+-----------+
| 11 | Layer 3 Address Group | Reflected Test | RFC 10052 |
| | | Packet Control | |
+-------+-----------------------+----------------+-----------+
Table 3: STAMP Sub-TLV Types for the Reflected Test Packet Control TLV
表3: Reflected Test Packet Control TLV 用の STAMP Sub-TLV Types
[IANA-STAMP]
IANA, "STAMP Sub-TLV Types",
<https://www.iana.org/assignments/stamp-tlv-types>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[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>.
[RFC7497] Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, April 2015, <https://www.rfc-editor.org/info/rfc7497>.
[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>.
[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>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.
[RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, October 2023, <https://www.rfc-editor.org/info/rfc9503>.
[RFC9946] Morton, A., Ciavattone, L., and R. Geib, Ed., "The UDP Speed Test Protocol (UDPSTP) for One-Way IP Capacity Metric Measurement", RFC 9946, DOI 10.17487/RFC9946, April 2026, <https://www.rfc-editor.org/info/rfc9946>.
[IEEE-802.3-2022]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436, July 2022,
<https://doi.org/10.1109/IEEESTD.2022.9844436>.
[IEEE-802.15.4-2024]
IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
December 2024,
<https://doi.org/10.1109/IEEESTD.2024.10794632>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-Way IP Capacity", RFC 9097, DOI 10.17487/RFC9097, November 2021, <https://www.rfc-editor.org/info/rfc9097>.
The authors thank Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe Fioccola, Xiao Min, Greg White, and Rohan Bhosle for their thorough reviews and helpful suggestions, which improved the document.
著者らは、Zhang Li、Ruediger Geib、Rakesh Gandhi、Giuseppe Fioccola、Xiao Min、Greg White、Rohan Bhosle の各氏による綿密なレビューと有益な提案に感謝します。これらは本書を改善しました。
Greg Mirsky
Ciena Corporation
Email: gregimirsky@gmail.com
Ernesto Ruffini
OutSys
Email: eruffini@outsys.org
Henrik Nydell
Cisco Systems
Email: hnydell@cisco.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Will Hawkins
University of Cincinnati
Email: hawkinsw@obs.cr