[要約] Segment Routing（SR）はソースルーティングのパラダイムを活用しています。SRはMultiprotocol Label Switching（SR-MPLS）とIPv6（SRv6）のフォワーディングプレーンの両方に適用されます。この文書は、SRネットワーク向けのSimple Two-Way Active Measurement Protocol（STAMP）拡張機能を、RFC 8972で定義されたオプションの拡張機能を補完する形で、SR-MPLSおよびSRv6のフォワーディングプレーンについて指定しています。
Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 9503 C. Filsfils
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 M. Chen
Huawei
B. Janssens
Colt
R. Foote
Nokia
October 2023
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies Simple Two-Way Active Measurement Protocol (STAMP) extensions (as described in RFC 8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972.
セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。SRは、マルチプロトコルラベルスイッチング（SR-MPLS）とIPv6（SRV6）転送面の両方に適用できます。このドキュメントは、RFC 8972で定義されたオプションの拡張機能を強化することにより、SR-MPLSとSRV6転送面のSRネットワークの単純な双方向アクティブ測定プロトコル（STAMP）拡張機能（RFC 8762で説明されている）を指定します。
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/rfc9503.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9503で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
2.1. Requirements Language
2.2. Abbreviations
2.3. Reference Topology
3. Destination Node Address TLV
4. Return Path TLV
4.1. Return Path Sub-TLVs
4.1.1. Return Path Control Code Sub-TLV
4.1.2. Return Address Sub-TLVs
4.1.3. Return Path Segment List Sub-TLVs
5. Interoperability with TWAMP Light
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Destination Node Address TLV Use-Case Example
Acknowledgments
Contributors
Authors' Addresses
Segment Routing (SR) leverages the source routing paradigm for Software-Defined Networks (SDNs). SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes [RFC8402]. SR Policies as defined in [RFC9256] are used to steer traffic through specific, user-defined paths using a stack of Segments. A comprehensive SR Performance Measurement (PM) toolset is one of the essential requirements to measure network performance to provide Service Level Agreements (SLAs).
セグメントルーティング（SR）は、ソフトウェア定義ネットワーク（SDNS）のソースルーティングパラダイムを活用します。SRは、マルチプロトコルラベルスイッチング（SR-MPLS）とIPv6（SRV6）転送面[RFC8402]の両方に適用できます。[RFC9256]で定義されているSRポリシーは、セグメントのスタックを使用して特定のユーザー定義のパスを介してトラフィックを操縦するために使用されます。包括的なSRパフォーマンス測定（PM）ツールセットは、ネットワークパフォーマンスを測定してサービスレベル契約（SLA）を提供するための重要な要件の1つです。
The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks [RFC8762] without the use of a control channel to pre-signal session parameters. [RFC8972] defines optional extensions, in the form of TLVs, for STAMP. Note that the YANG data model defined in [IPPM-STAMP-YANG] can be used to provision the STAMP Session-Sender and STAMP Session-Reflector.
シンプルな双方向アクティブ測定プロトコル（スタンプ）は、コントロールチャネルを使用せずに、シグナル前セッションパラメーターを使用せずに、IPネットワークのさまざまなパフォーマンスメトリック[RFC8762]の測定の機能を提供します。[RFC8972]スタンプ用のTLVの形式で、オプションの拡張機能を定義します。[IPPM-Stamp-Yang]で定義されているYangデータモデルを使用して、スタンプセッションセンダーとスタンプセッションリフレクターのプロビジョニングに使用できることに注意してください。
STAMP test packets are transmitted along an IP path between a Session-Sender and a Session-Reflector to measure performance delay and packet loss along that IP path. In SR networks, it may be desired that the same path (same set of links and nodes) between the Session-Sender and Session-Reflector be used for the STAMP test packets in both directions. This is achieved by using the STAMP [RFC8762] extensions for SR-MPLS and SRv6 networks as specified in this document by augmenting the optional extensions defined in [RFC8972].
スタンプテストパケットは、セッションセンダーとセッションリフェクターの間のIPパスに沿って送信され、そのIPパスに沿ったパフォーマンスの遅延とパケットの損失を測定します。SRネットワークでは、セッションセンダーとセッションリフェクターの間の同じパス（同じリンクとノードのセット）を両方向のスタンプテストパケットに使用することが望まれる場合があります。これは、[RFC8972]で定義されたオプションの拡張機能を拡張することにより、このドキュメントで指定されているように、SR-MPLSおよびSRV6ネットワークのスタンプ[RFC8762]拡張機能を使用することによって達成されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
SID:
シド：
Segment Identifier
セグメント識別子
SR:
SR：
Segment Routing
セグメントルーティング
SR-MPLS:
sr-mpls：
Segment Routing over MPLS
MPLS上のセグメントルーティング
SRv6:
SRV6：
Segment Routing over IPv6
IPv6を介したセグメントルーティング
SSID:
SSID：
STAMP Session Identifier
スタンプセッション識別子
STAMP:
スタンプ：
Simple Two-Way Active Measurement Protocol
単純な双方向アクティブ測定プロトコル
In the reference topology shown below, the STAMP Session-Sender S1 initiates a STAMP test packet and the STAMP Session-Reflector R1 transmits a reply STAMP test packet. The reply test packet may be transmitted to the Session-Sender S1 on the same path (same set of links and nodes) or a different path in the reverse direction from the path taken towards the Session-Reflector R1.
以下に示す参照トポロジでは、スタンプセッションセンダーS1がスタンプテストパケットを開始し、スタンプセッション - レフレクターR1が返信スタンプテストパケットを送信します。返信テストパケットは、同じパス（同じリンクとノードのセット）でセッションセンダーS1に送信されるか、セッションリフレクターR1に向かって取られたパスから逆方向に異なるパスを送信できます。
T1 is a transmit timestamp, and T4 is a receive timestamp added by node S1. T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1.
T1は送信タイムスタンプであり、T4はノードS1によって追加された受信タイムスタンプです。T2は受信タイムスタンプであり、T3はノードR1によって追加された送信タイムスタンプです。
The nodes S1 and R1 may be connected via a link or an SR path [RFC8402]. The link may be a physical interface, virtual link, Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member. The SR path may be an SR Policy [RFC9256] on node S1 (called "head-end") with a destination to node R1 (called "tail-end").
ノードS1およびR1は、リンクまたはSRパス[RFC8402]を介して接続できます。リンクは、物理インターフェイス、仮想リンク、リンク集約グループ（LAG）[IEEE802.1AX]、またはLAGメンバーです。SRパスは、ノードR1（「テールエンド」と呼ばれる）の宛先を備えたノードS1（「ヘッドエンド」と呼ばれる）のSRポリシー[RFC9256]です。
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: Reference Topology
図1：参照トポロジ
The Session-Sender may need to transmit test packets to the Session-Reflector with a Destination Address that is not a routable address (i.e., not suitable for use as the Source Address of the reply test packet) of the Session-Reflector. This can be facilitated, for example, by encapsulating the STAMP packet by a tunneling protocol; see Appendix A for an example.
セッションセンダーは、セッションリフレクターのルーティング可能なアドレスではない宛先アドレス（つまり、返信テストパケットのソースアドレスとして使用するのに適していない）で、テストパケットをセッションリフレクターに送信する必要があります。これは、たとえば、トンネリングプロトコルによってスタンプパケットをカプセル化することにより、促進できます。例については、付録Aを参照してください。
[RFC8972] defines STAMP Session-Sender and Session-Reflector test packets that can include one or more optional TLVs. In this document, the TLV Type (value 9 for IPv4 and IPv6) is defined for the Destination Node Address TLV for the STAMP test packet [RFC8972]. The formats of the Destination Node Address TLVs are shown in Figure 2:
[RFC8972] 1つ以上のオプションのTLVを含む可能性のあるスタンプセッションセンダーとセッションリフレクターテストパケットを定義します。このドキュメントでは、TLVタイプ（IPv4およびIPv6の値9）は、スタンプテストパケット[RFC8972]の宛先ノードアドレスTLVに対して定義されています。宛先ノードアドレス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=9 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=9 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Destination Node Address TLV Formats
図2：宛先ノードアドレスTLV形式
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
STAMP TLV Flags:
スタンプTLVフラグ：
The STAMP TLV Flags follow the procedures described in [RFC8972] and this document.
スタンプTLVフラグは、[RFC8972]およびこのドキュメントに記載されている手順に従います。
Type:
タイプ：
Type (value 9) for the IPv4 Destination Node Address TLV or IPv6 Destination Node Address TLV.
IPv4宛先ノードアドレスTLVまたはIPv6宛先ノードアドレスTLVのタイプ（値9）。
Length:
長さ：
A 2-octet field equal to the length of the Address field in octets. The length is 4 octets for an IPv4 address and 16 octets for an IPv6 address.
オクテットのアドレスフィールドの長さに等しい2-OCTETフィールド。長さは、IPv4アドレスの場合は4オクテット、IPv6アドレスの16オクテットです。
The Destination Node Address TLV indicates an address of the intended Session-Reflector node of the test packet. If the received Destination Node Address is one of the addresses of the Session-Reflector, it SHOULD be used as the Source Address in the IP header of the reply test packet. If the Destination Node Address TLV is sent, the SSID MUST also be sent.
宛先ノードアドレスTLVは、テストパケットの意図したセッションリフレクターノードのアドレスを示します。受信された宛先ノードアドレスがセッションリフェクターのアドレスの1つである場合、Reply Test PacketのIPヘッダーのソースアドレスとして使用する必要があります。宛先ノードアドレスTLVが送信される場合、SSIDも送信する必要があります。
A Session-Reflector that recognizes this TLV MUST set the U flag [RFC8972] in the reply test packet to 1 if the Session-Reflector determined that it is not the intended destination as identified in the Destination Node Address TLV. In this case, the Session-Reflector does not use the received Destination Node Address as the Source Address in the IP header of the reply test packet. Otherwise, the Session-Reflector MUST set the U flag in the Destination Node Address TLV in the reply test packet to 0.
このTLVを認識するセッションリフレクターは、セッションリフレクターが宛先ノードノードアドレスTLVで識別された宛先ではないと判断した場合、ReplyテストパケットにUフラグ[RFC8972]を1に設定する必要があります。この場合、セッションリフレクターは、Reply Test PacketのIPヘッダーのソースアドレスとして受信された宛先ノードアドレスを使用しません。それ以外の場合、セッションリフレクターは、宛先ノードアドレスTLVにuフラグを返信テストパケットの0に設定する必要があります。
For end-to-end SR paths, the Session-Reflector may need to transmit the reply test packet on a specific Return Path. The Session-Sender can request this in the test packet to the Session-Reflector using a Return Path TLV. With this TLV carried in the Session-Sender test packet, signaling and maintaining dynamic SR network state for the STAMP sessions on the Session-Reflector are avoided.
エンドツーエンドのSRパスの場合、セッションリフレクターは、特定のリターンパスで応答テストパケットを送信する必要がある場合があります。セッションセンダーは、リターンパスTLVを使用して、テストパケットでセッションリフェクターにこれを要求できます。このTLVがセッションセンダーテストパケットに搭載されているため、セッションリフレクターのスタンプセッションのための動的なSRネットワーク状態のシグナリングと維持は回避されます。
There are two modes defined for the behaviors on the Session-Reflector in Section 4 of [RFC8762]: Stateless and Stateful. A Stateful Session-Reflector requires configuration that must match all Session-Sender parameters, including the Source Address, Destination Address, Source UDP Port, Destination UDP Port, and possibly SSID (assuming the SSID is configurable and not auto-generated). In this case, a local policy can be used to direct the test packet by creating additional states for the STAMP sessions on the Session-Reflector. In the case of promiscuous operation, the Stateless Session-Reflector will require an indication of how to return the test packet on a specific path, for example, for measurement in an ECMP environment.
[RFC8762]のセクション4のセッションリフェクターの動作に対して定義された2つのモードがあります：ステートレスとステートフル。Stateful Session-Reflectorには、ソースアドレス、宛先アドレス、ソースUDPポート、宛先UDPポート、および場合によってはSSIDなど、すべてのセッションセンダーパラメーターと一致する必要がある構成が必要です（SSIDが設定可能であり、自動生成されていないと仮定）。この場合、ローカルポリシーを使用して、セッションリフレクターのスタンプセッション用に追加の状態を作成することにより、テストパケットを指示できます。無差別な操作の場合、Statelessセッションリフレクターは、たとえばECMP環境での測定のために、特定のパスでテストパケットを返す方法を示す必要があります。
For links, the Session-Reflector may need to transmit the reply test packet on the same incoming link in the reverse direction. The Session-Sender can request this in the test packet to the Session-Reflector using a Return Path TLV.
リンクの場合、セッションリフレクターは、同じ着信リンクに逆方向に返信テストパケットを送信する必要がある場合があります。セッションセンダーは、リターンパスTLVを使用して、テストパケットでセッションリフェクターにこれを要求できます。
[RFC8972] defines STAMP test packets that can include one or more optional TLVs. In this document, the TLV Type (value 10) is defined for the Return Path TLV that carries the Return Path for the Session-Sender test packet. The format of the Return Path TLV is shown in Figure 3:
[RFC8972] 1つ以上のオプションのTLVを含むスタンプテストパケットを定義します。このドキュメントでは、TLVタイプ（値10）は、セッションセンダーテストパケットのリターンパスを運ぶリターンパスTLVに対して定義されています。リターンパス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Sub-TLVs |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Return Path TLV Format
図3：パスTLV形式を返す
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
STAMP TLV Flags:
スタンプTLVフラグ：
The STAMP TLV Flags follow the procedures described in [RFC8972] and this document.
スタンプTLVフラグは、[RFC8972]およびこのドキュメントに記載されている手順に従います。
Type:
タイプ：
Type (value 10) for the Return Path TLV.
リターンパスTLVのタイプ（値10）。
Length:
長さ：
A 2-octet field equal to the length of the Return Path Sub-TLVs field in octets.
オクテットのリターンパスサブTLVSフィールドの長さに等しい2-OCTETフィールド。
Return Path Sub-TLVs:
PATH SUB-TLVを返す：
As defined in Section 4.1.
セクション4.1で定義されています。
A Session-Sender MUST NOT insert more than one Return Path TLV in the STAMP test packet. A Session-Reflector that supports this TLV MUST only process the first Return Path TLV in the test packet and ignore other Return Path TLVs if present. A Session-Reflector that supports this TLV MUST reply using the Return Path received in the Session-Sender test packet, if no error was encountered while processing the TLV.
セッションセンダーは、スタンプテストパケットに複数のリターンパスTLVを挿入してはなりません。このTLVをサポートするセッションリフェクターは、テストパケットで最初の戻りパスTLVを処理し、存在する場合は他のリターンパスTLVを無視する必要があります。このTLVをサポートするセッションリフレクターは、TLVの処理中にエラーが発生しなかった場合、セッションセンダーテストパケットで受信したリターンパスを使用して返信する必要があります。
A Session-Reflector that recognizes this TLV MUST set the U flag [RFC8972] in the reply test packet to 1 if the Session-Reflector determined that it cannot use the Return Path in the test packet to transmit the reply test packet. Otherwise, the Session-Reflector MUST set the U flag in the reply test packet to 0.
このTLVを認識するセッションリフレクターは、セッション再フラフレクターがテストパケットのリターンパスを使用して返信テストパケットを送信できないと判断した場合、ReplyテストパケットにUフラグ[RFC8972]を1に設定する必要があります。それ以外の場合、セッションリフレクターは、返信テストパケットのUフラグを0に設定する必要があります。
The Return Path TLV contains one or more Sub-TLVs to carry the information for the requested Return Path. A Return Path Sub-TLV can carry a Return Path Control Code, Return Path IP Address, or Return Path Segment List.
リターンパスTLVには、要求されたリターンパスの情報を携帯するための1つ以上のサブTLVが含まれています。Return Path Sub-TLVは、戻りパス制御コード、返品パスIPアドレス、またはパスセグメントリストを返すことができます。
The STAMP Sub-TLV Flags are set using the procedures described in [RFC8972].
スタンプサブTLVフラグは、[RFC8972]で説明されている手順を使用して設定されます。
A Return Path TLV MUST NOT contain more than one Control Code Sub-TLV, Return Address Sub-TLV, or Return Path Segment List Sub-TLV in a Session-Sender test packet.
リターンパスTLVには、セッションセンダーテストパケットに1つ以上のコントロールコードSub-TLV、Return Address Sub-TLV、またはReturn Path Segment List Sub-TLVが含まれている必要があります。
A Return Path TLV MUST NOT contain both a Control Code Sub-TLV and a Return Address or Return Path Segment List Sub-TLV in a Session-Sender test packet.
リターンパスTLVには、セッションセンダーテストパケットにコントロールコードSub-TLVと返信パスセグメントリストサブTLVの両方を含めてはなりません。
A Return Path TLV MAY contain both a Return Address and a Return Path Segment List Sub-TLV in a Session-Sender test packet.
リターンパスTLVには、セッションセンダーテストパケットに戻るアドレスとリターンパスセグメントリストサブTLVを含めることができます。
The format of the Control Code Sub-TLV in the Return Path TLV is shown in Figure 4.
リターンパスTLVのコントロールコードSub-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=1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Code Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Control Code Sub-TLV in the Return Path TLV
図4：リターンパスTLVのコントロールコードSub-TLVの形式
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
Type:
タイプ：
Type (value 1) for the Return Path Control Code. The Session-Sender can request the Session-Reflector to transmit the reply test packet based on the flags defined in the Control Code Flags field.
リターンパス制御コードのタイプ（値1）。セッションセンダーは、セッションリフレクターに、コントロールコードフラグフィールドで定義されているフラグに基づいて応答テストパケットを送信するように要求できます。
STAMP TLV Flags:
スタンプTLVフラグ：
The STAMP TLV Flags follow the procedures described in [RFC8972] and this document.
スタンプTLVフラグは、[RFC8972]およびこのドキュメントに記載されている手順に従います。
Length:
長さ：
A 2-octet field equal to the length of the Control Code flags, which is 4 octets.
コントロールコードフラグの長さ（4オクテット）に等しい2-OCTETフィールド。
Control Code Flags (32 bits):
コントロールコードフラグ（32ビット）：
0x0:
0x0：
No Reply Requested
返信は要求されていません
0x1:
0x1：
Reply Requested on the Same Link
同じリンクでリクエストされた返信
Reply Request Flag at bit 31 (least significant bit) is defined as follows. 0x0: No Reply Requested 0x1: Reply Requested on the Same Link
ビット31（最小重要なビット）の返信要求フラグは、次のように定義されています。0x0：返信なし0x1：同じリンクで返信要求
All other bits are reserved and must be transmitted as 0 and ignored by the receiver.
他のすべてのビットは予約されており、0として送信され、受信機によって無視する必要があります。
When Control Code flag for Reply Request is set to 0x0 in the Session-Sender test packet, the Session-Reflector does not transmit a reply test packet to the Session-Sender and terminates the STAMP test packet. Only the one-way measurement is applicable in this case. Optionally, the Session-Reflector may locally stream performance metrics via telemetry using the information from the received test packet. All other Return Path Sub-TLVs MUST be ignored in this case.
セッションセンダーテストパケットで返信要求のコントロールコードフラグが0x0に設定されている場合、セッションリフレクターは応答テストパケットをセッションセンダーに送信せず、スタンプテストパケットを終了します。この場合、一方向測定のみが適用されます。オプションで、セッションリフレクターは、受信したテストパケットからの情報を使用して、テレメトリーを介してパフォーマンスメトリックをローカルにストリーミングできます。この場合、他のすべてのリターンパスサブTLVは無視する必要があります。
When Control Code flag for Reply Request is set to 0x1 in the Session-Sender test packet, the Session-Reflector transmits the reply test packet over the same incoming link where the test packet is received in the reverse direction towards the Session-Sender. The link may be a physical interface, virtual link, LAG [IEEE802.1AX], or LAG member. All other Return Path Sub-TLVs MUST be ignored in this case. When using LAG member links, the STAMP extension for the Micro-Session ID TLV defined in [STAMP-ON-LAG] can be used to identify the link.
セッションセンダーテストパケットで返信要求のコントロールコードフラグが0x1に設定されている場合、セッションリフレクターは、テストパケットがセッションセンダーに向かって逆方向に受信される同じ着信リンクに応答テストパケットを送信します。リンクは、物理インターフェイス、仮想リンク、LAG [IEEE802.1AX]、またはLAGメンバーである場合があります。この場合、他のすべてのリターンパスサブTLVは無視する必要があります。LAGメンバーリンクを使用する場合、[スタンプオンラグ]で定義されたマイクロセッションID TLVのスタンプ拡張機能を使用してリンクを識別できます。
The STAMP reply test packet may be transmitted to the Session-Sender to the specified Return Address in the Return Address Sub-TLV instead of transmitting to the Source Address in the Session-Sender test packet.
Stamp Reply Test Packetは、セッションセンダーテストパケットのソースアドレスに送信する代わりに、セッションセンダーに指定された返信アドレスに送信された返信アドレスに送信される場合があります。
The formats of the IPv4 and IPv6 Return Address Sub-TLVs in the Return Path TLV are shown in Figure 5.
IPv4およびIPv6のリターンパスTLVの返品アドレスサブTLVの形式を図5に示します。
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=2 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=2 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Return IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Formats of the Return Address Sub-TLVs in the Return Path TLV
図5：戻りパスTLVの返品アドレスサブTLVの形式
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
Type:
タイプ：
Type (value 2) for the Return IPv4 Address or Return IPv6 Address.
IPv4アドレスを返すか、IPv6アドレスを返すためにタイプ（値2）。
The Return Address requests that the Session-Reflector reply test packet be sent to the specified address rather than to the Source Address in the Session-Sender test packet.
返信先アドレスは、セッション - センダーテストパケットのソースアドレスではなく、セッションリフレクター返信テストパケットを指定されたアドレスに送信することを要求します。
STAMP TLV Flags:
スタンプTLVフラグ：
The STAMP TLV Flags follow the procedures described in [RFC8972] and this document.
スタンプTLVフラグは、[RFC8972]およびこのドキュメントに記載されている手順に従います。
Length:
長さ：
A 2-octet field equal to the length of the Return Address field in octets. The length is 4 octets for an IPv4 address and 16 octets for an IPv6 address.
オクテットの返品アドレスフィールドの長さに等しい2-OCTETフィールド。長さは、IPv4アドレスの場合は4オクテット、IPv6アドレスの16オクテットです。
The format of the Segment List Sub-TLVs in the Return Path TLV is shown in Figures 6 and 7. The Segments carried in Segment List Sub-TLVs are described in [RFC8402]. The segment entries MUST be in network order.
リターンパスTLVのセグメントリストサブTLVの形式を図6および7に示します。セグメントエントリはネットワークの順序でなければなりません。
The Session-Sender MUST only insert one Return Path Segment List Sub-TLV in the test packet, and the Segment List MUST contain at least one Segment. The Session-Reflector MUST only process the first Return Path Segment List Sub-TLV in the test packet and ignore other Return Path Segment List Sub-TLVs if present.
セッションセンダーは、テストパケットに1つのリターンパスセグメントリストサブTLVのみを挿入する必要があり、セグメントリストには少なくとも1つのセグメントを含める必要があります。セッションリフレクターは、テストパケットで最初のリターンパスセグメントリストサブTLVを処理し、存在する場合は他のリターンパスセグメントリストサブTLVを無視する必要があります。
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
The Return Path Segment List Sub-TLV can be one of the following Types:
リターンパスセグメントリストSub-TLVは、次のタイプのいずれかになります。
Type (value 3):
タイプ（値3）：
SR-MPLS Label Stack of the Return Path
sr-mplsは、リターンパスのスタックをラベル付けします
Type (value 4):
タイプ（値4）：
SRv6 Segment List of the Return Path
SRV6セグメントリターンパスのリスト
Type (value 3): SR-MPLS Label Stack of the Return Path Type (value 4): SRv6 Segment List of the Return Path
タイプ（値3）：リターンパスのSR-MPLSラベルスタックタイプ（値4）：srv6セグメントリターンパスのリスト
STAMP TLV Flags:
スタンプTLVフラグ：
The STAMP TLV Flags follow the procedures described in [RFC8972] and this document.
スタンプTLVフラグは、[RFC8972]およびこのドキュメントに記載されている手順に従います。
Length:
長さ：
A 2-octet field equal to the length of the Segment List field in octets. The length MUST NOT be 0.
オクテットのセグメントリストフィールドの長さに等しい2-OCTETフィールド。長さは0ではありません。
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=3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(n) (bottom of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the SR-MPLS Label Stack Sub-TLV in the Return Path TLV
図6：sr-mplsラベルスタックsub-tlvのフォーマットリターンパスTLV
The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entries (LSEs) that includes a 20-bit label value, an 8-bit Time-To-Live (TTL) value, a 3-bit Traffic Class (TC) value, and a 1-bit End-of-Stack (S) field. The length of the Sub-TLV modulo 4 MUST be 0.
SR-MPLSラベルスタックには、20ビットラベル値、8ビット時間からlive（TTL）値、3ビットトラフィッククラス（TC）を含む32ビットラベルスタックエントリ（LSE）のリストが含まれています。）値、および1ビットのスタックの終了フィールド。Sub-TLV Modulo 4の長さは0でなければなりません。
As an example, an SR-MPLS Label Stack Sub-TLV could carry only the Binding SID Label [PCE-BINDING-LABEL-SID] of the Return SR-MPLS Policy. The Binding SID Label of the Return SR-MPLS Policy is local to the Session-Reflector. The mechanism to signal the Binding SID Label to the Session-Sender is outside the scope of this document.
例として、SR-MPLSラベルスタックSub-TLVは、Return SR-MPLSポリシーのバインディングSIDラベル[PCEバインディングラベルSID]のみを搭載できます。Return SR-MPLSポリシーのバインディングSIDラベルは、セッションリフレクターにローカルです。バインディングSIDラベルをセッションセンダーに信号するメカニズムは、このドキュメントの範囲外です。
As another example, an SR-MPLS Label Stack Sub-TLV could include the Path Segment Identifier Label of the Return SR-MPLS Policy in the Segment List of the SR-MPLS Policy.
別の例として、SR-MPLSラベルスタックSub-TLVには、SR-MPLSポリシーのセグメントリストにReturn SR-MPLSポリシーのパスセグメント識別子ラベルを含めることができます。
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=4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment(1) (128-bit IPv6 Address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment(n) (128-bit IPv6 Address) (bottom of stack) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the SRv6 Segment List Sub-TLV in the Return Path TLV
図7：SRV6セグメントリストのフォーマットサブTLVリターンパスTLV
The SRv6 Segment List contains a list of 128-bit IPv6 addresses representing the SRv6 SIDs. The length of the Sub-TLV modulo 16 MUST be 0.
SRV6セグメントリストには、SRV6 SIDSを表す128ビットIPv6アドレスのリストが含まれています。Sub-TLV Modulo 16の長さは0でなければなりません。
As an example, a Return Path SRv6 Segment List Sub-TLV could carry only the SRv6 Binding SID [PCE-BINDING-LABEL-SID] of the Return SRv6 Policy. The SRv6 Binding SID of the Return SRv6 Policy is local to the Session-Reflector. The mechanism to signal the SRv6 Binding SID to the Session-Sender is outside the scope of this document.
例として、リターンパスSRV6セグメントリストサブTLVは、リターンSRV6ポリシーのSRV6結合SID [PCEバインディングラベルSID]のみを搭載できます。Return SRV6ポリシーのSRV6結合SIDは、セッションリフレクターにローカルです。SRV6バインディングSIDをセッションセンダーに合図するメカニズムは、このドキュメントの範囲外です。
As another example, a Return Path SRv6 Segment List Sub-TLV could include the SRv6 Path Segment Identifier of the Return SRv6 Policy in the Segment List of the SRv6 Policy.
別の例として、リターンパスSRV6セグメントリストSub-TLVには、SRV6ポリシーのセグメントリストにReturn SRV6ポリシーのSRV6パスセグメント識別子を含めることができます。
This document does not introduce any additional considerations for interoperability with the Two-Way Active Measurement Protocol (TWAMP) Light than those described in Section 4.6 of [RFC8762].
このドキュメントでは、[RFC8762]のセクション4.6に記載されているものよりも、双方向アクティブ測定プロトコル（TWAMP）光との相互運用性に関する追加の考慮事項は導入されていません。
As described in [RFC8762], there are two possible combinations for such an interoperability use case:
[RFC8762]で説明されているように、このような相互運用性のユースケースには2つの組み合わせがあります。
* STAMP Session-Sender with TWAMP Light Session-Reflector
* Twamp Light Session-Reflectorを備えたスタンプセッションセンダー
* TWAMP Light Session-Sender with STAMP Session-Reflector
* Stamp Session-Reflectorを備えたTwamp Light Session-Sender
If any of the STAMP extensions defined in this document are used by STAMP Session-Sender, the TWAMP Light Session-Reflector will view them as the Packet Padding field.
このドキュメントで定義されているスタンプ拡張機能のいずれかがスタンプセッションセンダーによって使用されている場合、Twamp Light Session-Reflectorはそれらをパケットパディングフィールドと見なします。
The security considerations specified in [RFC8762] and [RFC8972] also apply to the extensions defined in this document. Specifically, the authenticated mode and the message integrity protection using Hashed Message Authentication Code (HMAC), as defined in Section 4.4 of [RFC8762], also apply to the procedures described in this document.
[RFC8762]および[RFC8972]で指定されたセキュリティ上の考慮事項は、このドキュメントで定義されている拡張機能にも適用されます。具体的には、[RFC8762]のセクション4.4で定義されているように、ハッシュされたメッセージ認証コード（HMAC）を使用した認証モードとメッセージ整合性保護も、このドキュメントで説明されている手順にも適用されます。
STAMP uses the well-known UDP port number that could become a target of denial of service (DoS) or could be used to aid on-path attacks. Thus, the security considerations and measures to mitigate the risk of the attack documented in Section 6 of [RFC8545] equally apply to the STAMP extensions in this document.
Stampは、サービス拒否（DOS）の目標となる可能性のあるよく知られているUDPポート番号を使用したり、パス上の攻撃を支援するために使用したりすることができます。したがって、[RFC8545]のセクション6に文書化された攻撃のリスクを軽減するためのセキュリティ上の考慮事項と措置は、このドキュメントのスタンプ拡張機能に等しく適用されます。
If desired, attacks can be mitigated by performing basic validation checks of the timestamp fields (such as T2 is later than T1 in the reference topology in Section 2.3) in received reply test packets at the Session-Sender. The minimal state associated with these protocols also limit the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle.
必要に応じて、セッションセンダーで受信した返信テストパケットで、タイムスタンプフィールドの基本的な検証チェック（セクション2.3の参照トポロジのT1より遅い）を実行することにより、攻撃を軽減できます。これらのプロトコルに関連する最小の状態は、破損したまたは無効なテストパケットが単一のテストサイクルに引き起こされる可能性のある測定破壊の程度を制限します。
The usage of STAMP extensions defined in this document is intended for deployment in a single network administrative domain. As such, the Session-Sender address, Session-Reflector address, and Return Path are provisioned by the operator for the STAMP session. It is assumed that the operator has verified the integrity of the Return Path and identity of the far-end Session-Reflector.
このドキュメントで定義されているスタンプ拡張機能の使用は、単一のネットワーク管理ドメインでの展開を目的としています。そのため、セッションセンダーアドレス、セッションリフレクターアドレス、およびリターンパスは、スタンプセッションのオペレーターによってプロビジョニングされます。オペレーターは、ファーエンドセッションリフレクターのリターンパスとアイデンティティの完全性を確認したと想定されています。
The STAMP extensions defined in this document may be used for potential address spoofing. For example, a Session-Sender may specify a Return Path IP Address that is different from the Session-Sender address. The Session-Reflector MAY drop the Session-Sender test packet when it cannot determine whether the Return Path IP Address is local on the Session-Sender. To help the Session-Reflector to make that determination, the Return Path IP Address may also be provisioned by the operator, for example, in an access control list.
このドキュメントで定義されているスタンプ拡張は、潜在的なアドレススプーフィングに使用できます。たとえば、セッションセンダーは、セッションセンダーアドレスとは異なるリターンパスIPアドレスを指定する場合があります。セッションリフレクターは、セッションセンダーのリターンパスIPアドレスがローカルであるかどうかを判断できない場合、セッションセンダーテストパケットをドロップする場合があります。セッションリフレクターがその決定を行うのを支援するために、リターンパスIPアドレスは、たとえばアクセス制御リストでオペレーターによってプロビジョニングされる場合があります。
IANA has allocated a value for the Destination Address TLV Type and a value for the Return Path TLV Type from the IETF Review TLV range in the "STAMP TLV Types" registry [RFC8972] as follows.
IANAは、宛先アドレスTLVタイプの値と、「スタンプTLVタイプ」レジストリ[RFC8972]のIETFレビューTLV範囲からのリターンパスTLVタイプの値を次のように割り当てています。
+=======+=======================================+===========+
| Value | Description | Reference |
+=======+=======================================+===========+
| 9 | Destination Node IPv4 or IPv6 Address | RFC 9503 |
+-------+---------------------------------------+-----------+
| 10 | Return Path | RFC 9503 |
+-------+---------------------------------------+-----------+
Table 1: STAMP TLV Types
表1：スタンプTLVタイプ
IANA has created the "Return Path Sub-TLV Types" registry. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points shall be allocated according to Table 2:
IANAは「Return Path Sub-TLV型」レジストリを作成しました。このレジストリの範囲1〜175のすべてのコードポイントは、[RFC8126]で指定されている「IETFレビュー」手順に従って割り当てられます。[RFC8126]で指定されているように、範囲176〜239のコードポイントは、「最初に来る最初の提供」手順に従って割り当てられます。残りのコードポイントは、表2に従って割り当てられます。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 1-175 | IETF Review |
+---------+-------------------------+
| 176-239 | First Come First Served |
+---------+-------------------------+
| 240-251 | Experimental Use |
+---------+-------------------------+
| 252-254 | Private Use |
+---------+-------------------------+
Table 2: Return Path Sub-TLV Types Registry
表2：パスサブTLVタイプのレジストリを返します
IANA has allocated values for the following Sub-TLV Types in the "Return Path Sub-TLV Types" registry.
IANAは、「Return Path Sub-TLVタイプ」レジストリに次のサブTLV型に値を割り当てています。
+=======+========================================+===========+
| Value | Description | Reference |
+=======+========================================+===========+
| 0 | Reserved | RFC 9503 |
+-------+----------------------------------------+-----------+
| 1 | Return Path Control Code | RFC 9503 |
+-------+----------------------------------------+-----------+
| 2 | Return IPv4 or IPv6 Address | RFC 9503 |
+-------+----------------------------------------+-----------+
| 3 | SR-MPLS Label Stack of the Return Path | RFC 9503 |
+-------+----------------------------------------+-----------+
| 4 | SRv6 Segment List of the Return Path | RFC 9503 |
+-------+----------------------------------------+-----------+
| 255 | Reserved | RFC 9503 |
+-------+----------------------------------------+-----------+
Table 3: Return Path Sub-TLV Types
表3：パスサブTLVタイプを返します
IANA has created the "Return Path Control Code Flags" registry for Return Path Control Code Sub-TLVs. All code points in the bit position 31 (counting from bit 31 as the least significant bit) through 12 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the bit position 11 through 8 shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points shall be allocated according to Table 4:
IANAは、Return Path Control Code Sub-TLVの「Return Path Control Code Flags」レジストリを作成しました。[RFC8126]で指定されているように、ビット位置31（ビット31から最も有意なビットとしてカウントビット31から最も重要なビットとしてカウント）から12のすべてのコードポイントは、「IETFレビュー」手順に従って割り当てられます。ビット位置11〜8のコードポイントは、[RFC8126]で指定されている「最初に来る最初の提供」手順に従って割り当てられます。残りのコードポイントは、表4に従って割り当てられます。
+=======+=========================+
| Range | Registration Procedures |
+=======+=========================+
| 31-12 | IETF Review |
+-------+-------------------------+
| 11-8 | First Come First Served |
+-------+-------------------------+
| 7-4 | Experimental Use |
+-------+-------------------------+
| 3-0 | Private Use |
+-------+-------------------------+
Table 4: Return Path Control Code Flags Registry
表4：パス制御コードフラグレジストリを返します
IANA has allocated a value in the "Return Path Control Code Flags" registry as follows.
IANAは、次のように「Return Path Control Code Flags」レジストリに値を割り当てました。
+=======+===============+===========+
| Value | Description | Reference |
+=======+===============+===========+
| 31 | Reply Request | RFC 9503 |
+-------+---------------+-----------+
Table 5: Return Path Control Code Flags
表5：パス制御コードフラグを返します
[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>.
[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>.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE Std 802.1AX-2014,
DOI 10.1109/IEEESTD.2014.7055197, December 2014,
<https://doi.org/10.1109/IEEESTD.2014.7055197>.
[IPPM-STAMP-YANG]
Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", Work in
Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11,
13 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-stamp-yang-11>.
[PCE-BINDING-LABEL-SID]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/Segment Identifier
(SID) in PCE-based Networks.", Work in Progress, Internet-
Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
binding-label-sid-16>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
Assignments for the One-Way Active Measurement Protocol
(OWAMP) and the Two-Way Active Measurement Protocol
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
<https://www.rfc-editor.org/info/rfc8545>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[STAMP-ON-LAG]
Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi,
"Simple Two-Way Active Measurement Protocol Extensions for
Performance Measurement on LAG", Work in Progress,
Internet-Draft, draft-ietf-ippm-stamp-on-lag-05, 17
October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-stamp-on-lag-05>.
STAMP test packets can be encapsulated with 1) an SR-MPLS Label Stack and IPv4 header containing an IPv4 Destination Address from the 127/8 range or 2) an outer IPv6 header and a Segment Routing Header (SRH) with an inner IPv6 header containing an IPv6 Destination Address from the ::1/128 range.
スタンプテストパケットは、1）127/8範囲または2）IPv4宛先アドレスを含む1）SR-MPLSラベルスタックとIPv4ヘッダーでカプセル化できます。:: 1/128範囲のIPv6宛先アドレス。
In an ECMP environment, the hashing function in forwarding may decide the outgoing path using the Source Address, Destination Address, UDP ports, IPv6 flow-label, etc. from the packet. Hence, for IPv4, for example, different values of an IPv4 Destination Address from the 127/8 range may be used in the IPv4 header of the STAMP test packets to measure different ECMP paths. For IPv6, for example, different values of flow-label may be used in the IPv6 header of the STAMP test packets to measure different ECMP paths.
ECMP環境では、転送におけるハッシュ機能は、パケットからソースアドレス、宛先アドレス、UDPポート、IPv6フローラベルなどを使用して発信パスを決定する場合があります。したがって、たとえば、IPv4の場合、127/8範囲のIPv4宛先アドレスの異なる値を、異なるECMPパスを測定するために、スタンプテストパケットのIPv4ヘッダーで使用できます。たとえば、IPv6の場合、StampテストパケットのIPv6ヘッダーでは、異なるECMPパスを測定するために、フローラベルの異なる値を使用できます。
In those cases, the STAMP test packets may reach a node that is not the Session-Reflector for this STAMP session in an error condition, and this unintended node may transmit a reply test packet that can result in the reporting of invalid measurement metrics. The intended Session-Reflector address can be carried in the Destination Node Address TLV to help detect this error.
そのような場合、スタンプテストパケットは、エラー条件でこのスタンプセッションのセッションリフレクターではないノードに到達する可能性があり、この意図しないノードは、無効な測定メトリックのレポートにつながる可能性のある応答テストパケットを送信する場合があります。意図したセッションリフレクターアドレスを宛先ノードアドレスTLVに携帯することができ、このエラーを検出することができます。
The authors would like to thank Thierry Couture for the discussions on the use cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan Mishra, Tianran Zhou, Al Morton, Reshad Rahman, Zhenqiang Li, Frank Brockners, Henrik Nydell, and Cheng Li for providing comments and suggestions. Thank you to Joel Halpern for the Gen-ART review, Martin Duke for the AD review, and Kathleen Moriarty for the Security review. The authors would also like to thank Robert Wilton, Éric Vyncke, Paul Wouters, John Scudder, Roman Danyliw, Lars Eggert, Erik Kline, Warren Kumari, and Jim Guichard for the IESG review.
著者は、セグメントルーティングでのパフォーマンス測定のためのユースケースに関する議論について、Thierry Coutureに感謝したいと思います。著者はまた、コメントと提案を提供してくれたグレッグ・ミルスキー、マイク・コルディチェフ、ギャン・ミシュラ、ティアン・Zhou、アル・モートン、レスシャド・ラマン、フランク・ブロックナー、ヘンリック・ナイデル、チェン・リーにも感謝したいと思います。Gen-ArtレビューについてはJoel Halpern、広告レビューのMartin Duke、およびセキュリティレビューのKathleen Moriartyに感謝します。著者はまた、IESGレビューをしてくれたロバート・ウィルトン、エリック・ヴィンケ、エリック・ヴィンケ、ジョン・スカダー、ロマン・ダニリウ、ラース・エガート、エリック・クライン、ウォーレン・クマリ、ジム・ギチャードにも感謝したいと思います。
The following person has contributed substantially to this document:
次の人はこの文書に大きく貢献しています。
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
Richard Foote
Nokia
Email: footer.foote@nokia.com