RFC 9503 - セグメントルーティングネットワーク用のシンプルな双方向アクティブ測定プロトコル（スタンプ）拡張機能

セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。SRは、マルチプロトコルラベルスイッチング（SR-MPLS）とIPv6（SRV6）転送面の両方に適用できます。このドキュメントは、RFC 8972で定義されたオプションの拡張機能を強化することにより、SR-MPLSとSRV6転送面のSRネットワークの単純な双方向アクティブ測定プロトコル（STAMP）拡張機能（RFC 8762で説明されている）を指定します。

これは、インターネット標準トラックドキュメントです。

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9503で取得できます。

著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

セグメントルーティング（SR）は、ソフトウェア定義ネットワーク（SDNS）のソースルーティングパラダイムを活用します。SRは、マルチプロトコルラベルスイッチング（SR-MPLS）とIPv6（SRV6）転送面[RFC8402]の両方に適用できます。[RFC9256]で定義されているSRポリシーは、セグメントのスタックを使用して特定のユーザー定義のパスを介してトラフィックを操縦するために使用されます。包括的なSRパフォーマンス測定（PM）ツールセットは、ネットワークパフォーマンスを測定してサービスレベル契約（SLA）を提供するための重要な要件の1つです。

シンプルな双方向アクティブ測定プロトコル（スタンプ）は、コントロールチャネルを使用せずに、シグナル前セッションパラメーターを使用せずに、IPネットワークのさまざまなパフォーマンスメトリック[RFC8762]の測定の機能を提供します。[RFC8972]スタンプ用のTLVの形式で、オプションの拡張機能を定義します。[IPPM-Stamp-Yang]で定義されているYangデータモデルを使用して、スタンプセッションセンダーとスタンプセッションリフレクターのプロビジョニングに使用できることに注意してください。

スタンプテストパケットは、セッションセンダーとセッションリフェクターの間のIPパスに沿って送信され、そのIPパスに沿ったパフォーマンスの遅延とパケットの損失を測定します。SRネットワークでは、セッションセンダーとセッションリフェクターの間の同じパス（同じリンクとノードのセット）を両方向のスタンプテストパケットに使用することが望まれる場合があります。これは、[RFC8972]で定義されたオプションの拡張機能を拡張することにより、このドキュメントで指定されているように、SR-MPLSおよびSRV6ネットワークのスタンプ[RFC8762]拡張機能を使用することによって達成されます。

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

MPLS：マルチプロトコルラベルスイッチング
SID：セグメント識別子
SR：セグメントルーティング
SR-MPLS：MPLS上のセグメントルーティング
SRV6：IPv6を介したセグメントルーティング
SSID：スタンプセッション識別子

スタンプ：シンプルな双方向アクティブ測定プロトコル

以下に示す参照トポロジでは、スタンプセッションセンダーS1がスタンプテストパケットを開始し、スタンプセッション - レフレクターR1が返信スタンプテストパケットを送信します。返信テストパケットは、同じパス（同じリンクとノードのセット）でセッションセンダーS1に送信されるか、セッションリフレクターR1に向かって取られたパスから逆方向に異なるパスを送信できます。

T1は送信タイムスタンプであり、T4はノードS1によって追加された受信タイムスタンプです。T2は受信タイムスタンプであり、T3はノードR1によって追加された送信タイムスタンプです。

ノードS1およびR1は、リンクまたはSRパス[RFC8402]を介して接続できます。リンクは、物理インターフェイス、仮想リンク、リンク集約グループ（LAG）[IEEE802.1AX]、またはLAGメンバーです。SRパスは、ノードR1（「テールエンド」と呼ばれる）の宛先を備えたノードS1（「ヘッドエンド」と呼ばれる）のSRポリシー[RFC9256]です。

                      T1                T2
                     /                   \
            +-------+     Test Packet     +-------+
            |       | - - - - - - - - - ->|       |
            |   S1  |=====================|   R1  |
            |       |<- - - - - - - - - - |       |
            +-------+  Reply Test Packet  +-------+
                     \                   /
                      T4                T3
 

スタンプセッションセンダースタンプセッションリフレクター
図1：参照トポロジ

セッションセンダーは、セッションリフレクターのルーティング可能なアドレスではない宛先アドレス（つまり、返信テストパケットのソースアドレスとして使用するのに適していない）で、テストパケットをセッションリフェクターに送信する必要があります。これは、たとえば、トンネリングプロトコルによってスタンプパケットをカプセル化することにより、促進できます。例については、付録Aを参照してください。

[RFC8972] 1つ以上のオプションのTLVを含む可能性のあるスタンプセッションセンダーとセッションリフレクターテストパケットを定義します。このドキュメントでは、TLVタイプ（IPv4およびIPv6の値9）は、スタンプテストパケット[RFC8972]の宛先ノードアドレスTLVに対して定義されています。宛先ノードアドレスTLVの形式を図2に示します。

図2：宛先ノードアドレスTLV形式

TLVフィールドは次のように定義されています。

スタンプTLVフラグ：スタンプTLVフラグは、[RFC8972]とこのドキュメントに記載されている手順に従います。

タイプ：IPv4宛先ノードアドレスTLVまたはIPv6宛先ノードアドレスTLVのタイプ（値9）。

長さ：オクテットのアドレスフィールドの長さに等しい2-OCTETフィールド。長さは、IPv4アドレスの場合は4オクテット、IPv6アドレスの16オクテットです。

宛先ノードアドレスTLVは、テストパケットの意図したセッションリフレクターノードのアドレスを示します。受信された宛先ノードアドレスがセッションリフェクターのアドレスの1つである場合、Reply Test PacketのIPヘッダーのソースアドレスとして使用する必要があります。宛先ノードアドレスTLVが送信される場合、SSIDも送信する必要があります。

このTLVを認識するセッションリフレクターは、セッションリフレクターが宛先ノードノードアドレスTLVで識別された宛先ではないと判断した場合、ReplyテストパケットにUフラグ[RFC8972]を1に設定する必要があります。この場合、セッションリフレクターは、Reply Test PacketのIPヘッダーのソースアドレスとして受信された宛先ノードアドレスを使用しません。それ以外の場合、セッションリフレクターは、宛先ノードアドレスTLVにuフラグを返信テストパケットの0に設定する必要があります。