[要約] RFC 9259は、IPv6のpingやtracerouteをSRv6ネットワークで使用する方法を説明し、SRH内のOAMフラグ（O-flag）を定義してセグメントエンドポイントからのフローサンプリングを行うことを目的としています。また、SRv6ドメイン内の任意のノード間でパスの連続性チェックを行うための中央監視システムの動作も記述しています。
Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 9259 C. Filsfils
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Matsushima
Softbank
D. Voyer
Bell Canada
M. Chen
Huawei
June 2022
Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)
IPv6（SRV6）を介したセグメントルーティングの運用、管理、およびメンテナンス（OAM）
Abstract
概要
This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain.
このドキュメントでは、PingおよびTracerouteの既存のIPv6メカニズムを、IPv6（SRV6）ネットワークを介したセグメントルーティングでどのように使用できるかについて説明します。このドキュメントは、セグメントエンドポイントから制御可能で予測可能なフローサンプリングを実行するために、セグメントルーティングヘッダー（SRH）のOAMフラグ（O-Flag）を指定します。さらに、ドキュメントでは、集中監視システムがSRV6ドメイン内のノード間でパス連続性チェックを実行する方法について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9259.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9259で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Abbreviations
1.3. Terminology and Reference Topology
2. OAM Mechanisms
2.1. OAM Flag in the Segment Routing Header
2.1.1. OAM Flag Processing
2.2. OAM Operations
3. Security Considerations
4. Privacy Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Illustrations
A.1. Ping in SRv6 Networks
A.1.1. Pinging an IPv6 Address via a Segment List
A.1.2. Pinging a SID
A.2. Traceroute in SRv6 Networks
A.2.1. Traceroute to an IPv6 Address via a Segment List
A.2.2. Traceroute to a SID
A.3. Hybrid OAM Using the OAM Flag
A.4. Monitoring of SRv6 Paths
Acknowledgements
Contributors
Authors' Addresses
As Segment Routing over IPv6 (SRv6) [RFC8402] simply adds a new type of Routing Extension Header, existing IPv6 OAM mechanisms can be used in an SRv6 network. This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in an SRv6 network. This includes illustrations of pinging an SRv6 Segment Identifier (SID) to verify that the SID is reachable and is locally programmed at the target node. This also includes illustrations for tracerouting to an SRv6 SID for hop-by-hop fault localization as well as path tracing to a SID.
IPv6（SRV6）[RFC8402]を介したセグメントルーティングは、新しいタイプのルーティング拡張ヘッダーを追加するだけで、既存のIPv6 OAMメカニズムをSRV6ネットワークで使用できます。このドキュメントでは、PingおよびTracerouteの既存のIPv6メカニズムをSRV6ネットワークで使用する方法について説明します。これには、SRV6セグメント識別子（SID）のpingingのイラストが含まれ、SIDが到達可能であり、ターゲットノードでローカルでプログラムされていることを確認します。これには、Hop-by-Hop障害のローカリゼーションのためのSRV6 SIDへのトレーサーのイラストと、SIDへのパストレースも含まれます。
This document also introduces enhancements for the OAM mechanism for SRv6 networks that allow controllable and predictable flow sampling from segment endpoints using, e.g., the IP Flow Information Export (IPFIX) protocol [RFC7011]. Specifically, the document specifies the OAM flag (O-flag) in the SRH as a marking bit in the user packets to trigger telemetry data collection and export at the segment endpoints.
このドキュメントでは、IPフロー情報エクスポート（IPFIX）プロトコル[RFC7011]を使用して、セグメントエンドポイントから制御可能で予測可能なフローサンプリングを可能にするSRV6ネットワークのOAMメカニズムの拡張機能も紹介します。具体的には、ドキュメントは、SRHのOAMフラグ（O-Flag）をユーザーパケットのマークビットとして指定して、テレメトリーのデータ収集とセグメントエンドポイントでエクスポートするトリガーをトリガーします。
This document also outlines how the centralized OAM technique in [RFC8403] can be extended for SRv6 to perform a path continuity check between any nodes within an SRv6 domain. Specifically, the document illustrates how a centralized monitoring system can monitor arbitrary SRv6 paths by creating loopback probes that originate and terminate at the centralized monitoring system.
このドキュメントでは、SRV6がSRV6ドメイン内のノード間でパス連続性チェックを実行するために[RFC8403]の集中化されたOAM技術をどのように拡張できるかを概説しています。具体的には、このドキュメントは、集中監視システムが集中監視システムで発生および終了するループバックプローブを作成することにより、任意のSRV6パスを監視する方法を示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following abbreviations are used in this document:
このドキュメントでは、次の略語が使用されています。
SID: Segment Identifier
SID：セグメント識別子
SL: Segments Left
SL：セグメントが残っています
SR: Segment Routing
SR：セグメントルーティング
SRH: Segment Routing Header [RFC8754]
SRH：セグメントルーティングヘッダー[RFC8754]
SRv6: Segment Routing over IPv6 [RFC8402]
SRV6：IPv6を介したセグメントルーティング[RFC8402]
PSP: Penultimate Segment Pop [RFC8986]
PSP：最後から2番目のセグメントPOP [RFC8986]
USP: Ultimate Segment Pop [RFC8986]
USP：究極のセグメントポップ[RFC8986]
ICMPv6: Internet Control Message Protocol for the Internet Protocol version 6 [RFC4443]
ICMPV6：インターネットプロトコルのインターネット制御メッセージプロトコルバージョン6 [RFC4443]
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
OSPF: Open Shortest Path First [RFC2328]
OSPF：最初に最短パスを開く[RFC2328]
IGP: Interior Gateway Protocol (e.g., OSPF and IS-IS)
IGP：インテリアゲートウェイプロトコル（例：OSPFやIS-IS）
BGP-LS: Border Gateway Protocol - Link State [RFC8571]
BGP -LS：Border Gateway Protocol -Link State [RFC8571]
The terminology and simple topology in this section are used for illustration throughout the document.
このセクションの用語と単純なトポロジは、ドキュメント全体の図に使用されます。
+--------------------------| N100 |---------------------------------+
| |
| ====== link1====== link3------ link5====== link9------ ====== |
||N1||------||N2||------| N3 |------||N4||------| N5 |---||N7||
|| ||------|| ||------| |------|| ||------| |---|| ||
====== link2====== link4------ link6======link10------ ======
| | | |
---+-- | ------ | --+---
|CE1 | +-------| N6 |---------+ |CE2 |
------ link7 | | link8 ------
------
Figure 1: Reference Topology
図1：参照トポロジ
In the reference topology:
参照トポロジ：
* Node j has an IPv6 loopback address 2001:db8:L:j::/128.
* ノードJにはIPv6ループバックアドレス2001があります：db8：l：j ::/128。
* Nodes N1, N2, N4, and N7 are SRv6-capable nodes.
* ノードN1、N2、N4、およびN7はSRV6対応ノードです。
* Nodes N3, N5, and N6 are IPv6 nodes that are not SRv6-capable nodes. Such nodes are referred to as "non-SRv6-capable nodes".
* ノードN3、N5、およびN6は、SRV6対応ノードではないIPv6ノードです。このようなノードは、「非SRV6対応ノード」と呼ばれます。
* CE1 and CE2 are Customer Edge devices of any data plane capability (e.g., IPv4, IPv6, and L2).
* CE1とCE2は、データプレーン機能（IPv4、IPv6、L2など）の顧客エッジデバイスです。
* A SID at node j with locator block 2001:db8:K::/48 and function U is represented by 2001:db8:K:j:U::.
* ロケーターブロック2001を備えたノードJのSID：db8：k ::/48およびfunction uは2001年までに表されます：db8：k：j：u ::。
* Node N100 is a controller.
* ノードN100はコントローラーです。
* The IPv6 address of the nth link between nodes i and j at the i side is represented as 2001:db8:i:j:in::. For example, in Figure 1, the IPv6 address of link6 (the second link between nodes N3 and N4) at node N3 is 2001:db8:3:4:32::. Similarly, the IPv6 address of link5 (the first link between nodes N3 and N4) at node N3 is 2001:db8:3:4:31::.
* I側のノードIとj間のn番目のリンクのIPv6アドレスは、2001：db8：i：j：in ::として表されます。たとえば、図1では、ノードN3のLink6（ノードN3とN4の間の2番目のリンク）のIPv6アドレスは2001：DB8：3：4：32 ::です。同様に、ノードN3のLink5のIPv6アドレス（ノードN3とN4の最初のリンク）は2001：DB8：3：4：31 ::です。
* 2001:db8:K:j:Xin:: is explicitly allocated as the End.X SID at node j towards neighbor node i via the nth link between nodes i and j. For example, 2001:db8:K:2:X31:: represents End.X at node N2 towards node N3 via link3 (the first link between nodes N2 and N3). Similarly, 2001:db8:K:4:X52:: represents the End.X at node N4 towards node N5 via link10 (the second link between nodes N4 and N5). Please refer to [RFC8986] for a description of End.X SID.
* 2001：db8：k：j：xin :: node jのend.x sidとして明示的に割り当てられます。ノードIとjの間のn番目のリンクを介してネイバーノードIに向かって。たとえば、2001年：db8：k：2：x31 ::は、link3（ノードn2とn3の最初のリンク）を介してノードn3にノードn2のend.xを表します。同様に、2001年：db8：k：4：x52 ::は、link10を介してノードn5に向かってノードn4のend.xを表します（ノードn4とn5の2番目のリンク）。End.x Sidの説明については、[RFC8986]を参照してください。
* A SID list is represented as <S1, S2, S3>, where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path.
* SIDリストは<S1、S2、S3>として表されます。ここで、S1は訪問した最初のSID、S2は訪問する2番目のSID、S3はSRパスに沿って最後に訪問するSIDです。
* (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with:
* （sa、da）（s3、s2、s1; sl）（ペイロード）は、次のipv6パケットを表します。
- IPv6 header with source address SA, destination address DA, and SRH as the next header
- 次のヘッダーとしてソースアドレスSA、宛先アドレスDA、およびSRHを備えたIPv6ヘッダー
- SRH with SID list <S1, S2, S3> with SegmentsLeft = SL
- SIDリスト付きSRH <S1、S2、S3> with SegmentsLeft = SL
Note the difference between the < > and () symbols: <S1, S2, S3> represents a SID list where S1 is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) represents the same SID list but encoded in the SRH format where the rightmost SID in the SRH is the first SID and the leftmost SID in the SRH is the last SID. When referring to an SR Policy in a high-level use case, it is simpler to use the <S1, S2, S3> notation. When referring to an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notation is more convenient.
<>と（）シンボルの違いに注意してください。（S3、S2、S1; SL）は同じSIDリストを表しますが、SRHの右端SIDが最初のSIDであり、SRHの左端のSIDが最後のSIDであるSRH形式でエンコードされています。高レベルのユースケースでSRポリシーを参照する場合、<S1、S2、S3>表記を使用する方が簡単です。詳細なパケット動作のイラストを参照する場合、（S3、S2、S1; SL）表記はより便利です。
- (payload) represents the payload of the packet.
- （ペイロード）は、パケットのペイロードを表します。
This section defines OAM enhancements for SRv6 networks.
このセクションでは、SRV6ネットワークのOAM強化を定義します。
[RFC8754] describes the Segment Routing Header (SRH) and how SR-capable nodes use it. The SRH contains an 8-bit Flags field.
[RFC8754]は、セグメントルーティングヘッダー（SRH）とSR対応ノードの使用方法について説明します。SRHには8ビットフラグフィールドが含まれています。
This document defines the following bit in the SRH Flags field to carry the O-flag:
このドキュメントでは、srhフラグフィールドの次のビットを定義して、o-flagを運びます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |O| |
+-+-+-+-+-+-+-+-+
Where:
ただし：
O-flag: OAM flag in the SRH Flags field defined in [RFC8754].
O-Flag：[RFC8754]で定義されているSRHフラグフィールドのOAMフラグ。
The O-flag in the SRH is used as a marking bit in user packets to trigger telemetry data collection and export at the segment endpoints.
SRHのO-Flagは、ユーザーパケットのマークビットとして使用され、テレメトリーデータ収集とセグメントエンドポイントでのエクスポートをトリガーします。
An SR domain ingress edge node encapsulates packets traversing the SR domain as defined in [RFC8754]. The SR domain ingress edge node MAY use the O-flag in the SRH for marking the packet to trigger the telemetry data collection and export at the segment endpoints. Based on local configuration, the SR domain ingress edge node may implement a classification and sampling mechanism to mark a packet with the O-flag in the SRH. Specification of the classification and sampling method is outside the scope of this document.
SRドメインイングレスエッジノードは、[RFC8754]で定義されているようにSRドメインを通過するパケットをカプセル化します。SRドメインイングレスエッジノードは、SRHのO-Flagを使用してパケットをマークして、テレメトリデータ収集をトリガーし、セグメントエンドポイントでエクスポートする場合があります。ローカル構成に基づいて、SRドメインイングレスエッジノードは、SRHのO-Flagでパケットをマークする分類およびサンプリングメカニズムを実装できます。分類およびサンプリング方法の仕様は、このドキュメントの範囲外です。
This document does not specify the data elements that need to be exported and the associated configurations. Similarly, this document does not define any formats for exporting the data elements. Nonetheless, without the loss of generality, this document assumes that the IP Flow Information Export (IPFIX) protocol [RFC7011] is used for exporting the traffic flow information from the network devices to a controller for monitoring and analytics. Similarly, without the loss of generality, this document assumes that requested information elements are configured by the management plane through data set templates (e.g., as in IPFIX [RFC7012]).
このドキュメントでは、エクスポートする必要があるデータ要素と関連する構成は指定されていません。同様に、このドキュメントは、データ要素をエクスポートするための形式を定義しません。それにもかかわらず、一般性の損失なしに、このドキュメントは、IPフロー情報エクスポート（IPFIX）プロトコル[RFC7011]が、監視と分析のためにネットワークデバイスからコントローラーにトラフィックフロー情報をエクスポートするために使用されることを前提としています。同様に、一般性を失うことなく、このドキュメントは、要求された情報要素がデータセットテンプレートを介して管理プレーンによって構成されることを前提としています（例：IPFIX [RFC7012]など）。
Implementation of the O-flag is OPTIONAL. If a node does not support the O-flag, then it simply ignores it upon reception. If a node supports the O-flag, it can optionally advertise its potential via control plane protocol(s).
O-Flagの実装はオプションです。ノードがO-Flagをサポートしていない場合、それは単に受信時にそれを無視します。ノードがO-Flagをサポートする場合、コントロールプレーンプロトコルを介してオプションでその可能性を宣伝できます。
The following is appended to line S01 of the pseudocode associated with the SID S (as defined in Section 4.3.1.1 of [RFC8754]) when N receives a packet destined to S, S is a local SID, and the O-flag is processed.
NがSに導くパケットを受信する場合、SIDに関連する擬似コードの線S01に追加されます（[RFC8754]のセクション4.3.1.1で定義）、SはローカルSIDであり、O-FLAGは処理されます。
S01.1. IF the O-flag is set and local configuration permits
O-flag processing {
a. Make a copy of the packet.
b. Send the copied packet, along with a timestamp,
to the OAM process for telemetry data collection
and export. ;; Ref1
}
Ref1: To provide an accurate timestamp, an implementation should
copy and record the timestamp as soon as possible during packet
processing. Timestamp and any other metadata are not carried in
the packet forwarded to the next hop.
Please note that the O-flag processing happens before execution of regular processing of the local SID S. Specifically, line S01.1 of the pseudocode specified in this document is inserted between lines S01 and S02 of the pseudocode defined in Section 4.3.1.1 of [RFC8754].
o-flag処理は、ローカルSID Sの定期処理の実行前に行われることに注意してください。特に、このドキュメントで指定された擬似コードの行S01.1は、セクション4.3.1.1で定義されている擬似コードの行S01とS02の間に挿入されています。[RFC8754]。
Based on the requested information elements configured by the management plane through data set templates [RFC7012], the OAM process exports the requested information elements. The information elements include parts of the packet header and/or parts of the packet payload for flow identification. The OAM process uses information elements defined in IPFIX [RFC7011] and Packet Sampling (PSAMP) [RFC5476] for exporting the requested sections of the mirrored packets.
データセットテンプレート[RFC7012]を介して管理プレーンによって構成された要求された情報要素に基づいて、OAMプロセスは要求された情報要素をエクスポートします。情報要素には、パケットヘッダーの一部および/またはフロー識別用のパケットペイロードの一部が含まれます。OAMプロセスは、Mirroredパケットの要求されたセクションをエクスポートするために、IPFIX [RFC7011]およびパケットサンプリング（PSAMP）[RFC5476]で定義されている情報要素を使用します。
If the penultimate segment of a segment list is a PSP SID, telemetry data from the ultimate segment cannot be requested. This is because, when the penultimate segment is a PSP SID, the SRH is removed at the penultimate segment, and the O-flag is not processed at the ultimate segment.
セグメントリストの最後から2番目のセグメントがPSP SIDである場合、究極のセグメントからのテレメトリデータを要求できません。これは、最後から2番目のセグメントがPSP SIDである場合、SRHが最後から2番目のセグメントで削除され、O-Flagが究極のセグメントで処理されないためです。
The processing node MUST rate-limit the number of packets punted to the OAM process to a configurable rate. This is to avoid impacting the performance of the OAM and telemetry collection processes. Failure to implement the rate limit can lead to a denial-of-service attack, as detailed in Section 3.
処理ノードは、OAMプロセスにパントされたパケットの数を構成可能なレートに格付けする必要があります。これは、OAMおよびテレメトリの収集プロセスのパフォーマンスに影響を与えることを避けるためです。セクション3で詳述されているように、レート制限を実装しないと、サービス拒否攻撃につながる可能性があります。
The OAM process MUST NOT process the copy of the packet or respond to any Upper-Layer header (like ICMP, UDP, etc.) payload to prevent multiple evaluations of the datagram.
OAMプロセスは、パケットのコピーを処理したり、上層層ヘッダー（ICMP、UDPなど）のペイロードに応答して、データグラムの複数の評価を防ぎません。
The OAM process is expected to be located on the routing node processing the packet. Although the specification of the OAM process or the external controller operations are beyond the scope of this document, the OAM process SHOULD NOT be topologically distant from the routing node, as this is likely to create significant security and congestion issues. How to correlate the data collected from different nodes at an external controller is also outside the scope of this document. Appendix A illustrates use of the O-flag for implementing a hybrid OAM mechanism, where the "hybrid" classification is based on [RFC7799].
OAMプロセスは、パケットを処理するルーティングノードに配置されると予想されます。OAMプロセスまたは外部コントローラー操作の仕様はこのドキュメントの範囲を超えていますが、OAMプロセスは、重大なセキュリティと輻輳の問題を引き起こす可能性が高いため、ルーティングノードからトポロジカルに離れてはなりません。外部コントローラーで異なるノードから収集されたデータを相関させる方法は、このドキュメントの範囲外でもあります。付録Aは、「ハイブリッド」分類が[RFC7799]に基づいているハイブリッドOAMメカニズムを実装するためのO-Flagの使用を示しています。
IPv6 OAM operations can be performed for any SRv6 SID whose behavior allows Upper-Layer header processing for an applicable OAM payload (e.g., ICMP, UDP).
IPv6 OAM操作は、該当するOAMペイロード（ICMP、UDPなど）の上層ヘッダー処理を可能にするSRV6 SIDに対して実行できます。
Ping to an SRv6 SID is used to verify that the SID is reachable and is locally programmed at the target node. Traceroute to a SID is used for hop-by-hop fault localization as well as path tracing to a SID. Appendix A illustrates the ICMPv6-based ping and UDP-based traceroute mechanisms for ping and traceroute to an SRv6 SID. Although this document only illustrates ICMPv6-based ping and UDP-based traceroute to an SRv6 SID, the procedures are equally applicable to other OAM mechanisms that probe an SRv6 SID (e.g., Bidirectional Forwarding Detection (BFD) [RFC5880], Seamless BFD (S-BFD) [RFC7880], and Simple Two-way Active Measurement Protocol (STAMP) probe message processing [STAMP-SR]). Specifically, as long as local configuration allows the Upper-Layer header processing of the applicable OAM payload for SRv6 SIDs, the existing IPv6 OAM techniques can be used to target a probe to a (remote) SID.
SRV6 SIDへのpingは、SIDが到達可能であり、ターゲットノードでローカルでプログラムされていることを確認するために使用されます。SIDへのTracerouteは、ホップバイホップ障害のローカリゼーションと、SIDへのパストレースに使用されます。付録Aは、ICMPV6ベースのPINGおよびUDPベースのTracerouteメカニズムと、SRV6 SIDへのPingおよびTracerouteのメカニズムを示しています。このドキュメントは、ICMPV6ベースのPingとUDPベースのTracerouteをSRV6 SIDに示していることのみを示していますが、手順はSRV6 SIDをプローブする他のOAMメカニズムに等しく適用できます（例：双方向転送検出（BFD）[RFC5880]、Seamless BFD（SEAMLESS BFD（S）-BFD）[RFC7880]、および単純な双方向アクティブ測定プロトコル（スタンプ）プローブメッセージ処理[Stamp-SR]）。具体的には、ローカル構成がSRV6 SIDSの該当するOAMペイロードの上層ヘッダー処理を可能にする限り、既存のIPv6 OAM技術を使用して、（リモート）SIDのプローブを標的とすることができます。
IPv6 OAM operations can be performed with the target SID in the IPv6 destination address without an SRH or with an SRH where the target SID is the last segment. In general, OAM operations to a target SID may not exercise all of its processing depending on its behavior definition. For example, ping to an End.X SID [RFC8986] only validates the SID is locally programmed at the target node and does not validate switching to the correct outgoing interface. To exercise the behavior of a target SID, the OAM operation should construct the probe in a manner similar to a data packet that exercises the SID behavior, i.e. to include that SID as a transit SID in either an SRH or IPv6 DA of an outer IPv6 header or as appropriate based on the definition of the SID behavior.
IPv6 OAM操作は、SRHなしでIPv6宛先アドレスのターゲットSIDまたはターゲットSIDが最後のセグメントであるSRHで実行できます。一般に、ターゲットSIDへのOAM操作は、動作の定義に応じてすべての処理を行使することはできません。たとえば、ping to and.x sid [rfc8986]は、SIDがターゲットノードでローカルにプログラムされていることのみを検証し、正しい発信インターフェイスへの切り替えを検証しません。ターゲットSIDの動作を行使するには、OAM操作は、SIDの動作を行使するデータパケットと同様の方法でプローブを構築する必要があります。ヘッダーまたは適切な場合、SIDの動作の定義に基づいています。
[RFC8754] defines the notion of an SR domain and use of the SRH within the SR domain. The use of OAM procedures described in this document is restricted to an SR domain. For example, similar to SID manipulation, O-flag manipulation is not considered a threat within the SR domain. Procedures for securing an SR domain are defined in Sections 5.1 and 7 of [RFC8754].
[RFC8754]は、SRドメインの概念とSRHドメイン内のSRHの使用を定義します。このドキュメントで説明されているOAM手順の使用は、SRドメインに制限されています。たとえば、SID操作と同様に、O-Flag操作はSRドメイン内の脅威とは見なされません。SRドメインを保護する手順は、[RFC8754]のセクション5.1および7で定義されています。
As noted in Section 7.1 of [RFC8754], compromised nodes within the SR domain may mount attacks. The O-flag may be set by an attacking node attempting a denial-of-service attack on the OAM process at the segment endpoint node. An implementation correctly implementing the rate limiting described in Section 2.1.1 is not susceptible to that denial-of-service attack. Additionally, SRH flags are protected by the Hashed Message Authentication Code (HMAC) TLV, as described in Section 2.1.2.1 of [RFC8754]. Once an HMAC is generated for a segment list with the O-flag set, it can be used for an arbitrary amount of traffic using that segment list with the O-flag set.
[RFC8754]のセクション7.1で述べたように、SRドメイン内の侵害されたノードは攻撃をマウントする可能性があります。O-Flagは、セグメントエンドポイントノードでOAMプロセスに対するサービス拒否攻撃を試みる攻撃ノードによって設定される場合があります。セクション2.1.1で説明されているレート制限を正しく実装する実装は、そのサービス拒否攻撃の影響を受けません。さらに、SRHフラグは、[RFC8754]のセクション2.1.2.1で説明されているように、ハッシュされたメッセージ認証コード（HMAC）TLVによって保護されています。O-Flagセットを備えたセグメントリスト用にHMACが生成されると、O-Flagセットを使用してそのセグメントリストを使用して、任意の量のトラフィックに使用できます。
The security properties of the channel used to send exported packets marked by the O-flag will depend on the specific OAM processes used. An on-path attacker able to observe this OAM channel could conduct traffic analysis, or potentially eavesdropping (depending on the OAM configuration), of this telemetry for the entire SR domain from such a vantage point.
O-Flagでマークされたエクスポートされたパケットを送信するために使用されるチャネルのセキュリティプロパティは、使用される特定のOAMプロセスによって異なります。このOAMチャネルを観察できるパス上の攻撃者は、このような見晴らしの良い場所からSRドメイン全体のこのテレメトリのトラフィック分析、または潜在的に盗聴（OAM構成に応じて）を実施する可能性があります。
This document does not impose any additional security challenges to be considered beyond the security threats described in [RFC4884], [RFC4443], [RFC0792], [RFC8754], and [RFC8986].
この文書は、[RFC4884]、[RFC4443]、[RFC0792]、[RFC8754]、および[RFC8986]に記載されているセキュリティの脅威を超えて考慮される追加のセキュリティ上の課題を課しません。
The per-packet marking capabilities of the O-flag provide a granular mechanism to collect telemetry. When this collection is deployed by an operator with the knowledge and consent of the users, it will enable a variety of diagnostics and monitoring to support the OAM and security operations use cases needed for resilient network operations. However, this collection mechanism will also provide an explicit protocol mechanism to operators for surveillance and pervasive monitoring use cases done contrary to the user's consent.
O-Flagのパケットごとのマーキング機能は、テレメトリを収集するためのきめ細かいメカニズムを提供します。このコレクションがユーザーの知識と同意を得てオペレーターによって展開されると、さまざまな診断と監視が可能になり、回復力のあるネットワーク操作に必要なOAMおよびセキュリティオペレーションのユースケースがサポートされます。ただし、この収集メカニズムは、ユーザーの同意に反して行われた監視および広範な監視ユースケースのために、演算子に明示的なプロトコルメカニズムを提供します。
IANA has registered the following in the "Segment Routing Header Flags" subregistry in the "Internet Protocol Version 6 (IPv6) Parameters" registry:
IANAは、「インターネットプロトコルバージョン6（IPv6）パラメーター」レジストリで「セグメントルーティングヘッダーフラグ」サブレジストリに以下を登録しました。
+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 2 | O-flag | RFC 9259 |
+-----+-------------+-----------+
Table 1
表1
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8754] Filsfils、C.、Ed。、Dukes、D.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、およびD. Voyer、「IPv6セグメントルーティングヘッダー（SRH）」、RFC8754、doi 10.17487/rfc8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
[RFC8986] Filsfils、C.、Ed。、Camarillo、P.、Ed。、Leddy、J.、Voyer、D.、Matsushima、S.、およびZ. Li、「IPv6（SRV6）ネットワークプログラミングを介したセグメントルーティング」、RFC 8986、DOI 10.17487/RFC8986、2021年2月、<https://www.rfc-editor.org/info/rfc8986>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] POSTEL、J。、「インターネットコントロールメッセージプロトコル」、STD 5、RFC 792、DOI 10.17487/RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487/RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、ed。、 "インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、STD 89、RFC 4443、DOI 10.17487/RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするためにICMPを拡張」、RFC 4884、DOI 10.17487/RFC4884、2007年4月、<https：///www.rfc-editor.org/info/rfc4884>。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009, <https://www.rfc-editor.org/info/rfc5476>.
[RFC5476] Claise、B.、Ed。、Johnson、A。、およびJ. Quittek、「パケットサンプリング（PSAMP）プロトコル仕様」、RFC 5476、DOI 10.17487/RFC5476、2009年3月、<https：//www.rfc-editor.org/info/rfc5476>。
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, April 2010, <https://www.rfc-editor.org/info/rfc5837>.
[RFC5837] Atlas、A.、ed。、Bonica、R.、ed。、Pignataro、C.、Ed。、Shen、N.、Jr。Rivers、「インターフェイスおよびネクストホップ識別のICMPの拡張」、RFC 5837、DOI 10.17487/RFC5837、2010年4月、<https://www.rfc-editor.org/info/rfc5837>
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487/RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、Ed。、Trammell、B.、Ed。、およびP. Aitken、「流れ情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、doi 10.17487/rfc7011、2013年9月、<https://www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.
[RFC7012] Claise、B.、ed。and B. Trammell編、「IPフロー情報エクスポートの情報モデル（IPFIX）」、RFC 7012、DOI 10.17487/RFC7012、2013年9月、<https://www.rfc-editor.org/info/rfc7012>。
[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>.
[RFC7799]モートン、A。、「アクティブおよびパッシブメトリックとメソッド（中間ハイブリッドタイプを含む）」、RFC 7799、DOI 10.17487/RFC7799、2016年5月、<https://www.rfc-editor.org/info/RFC7799>。
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/info/rfc7880>.
[RFC7880] Pignataro、C.、Ward、D.、Akiya、N.、Bhatia、M.、およびS. Pallagatti、「Seamless Bidelectional Forwarding Detection（S-BFD）」、RFC 7880、DOI 10.17487/RFC780、2016年7月、<https://www.rfc-editor.org/info/rfc7880>。
[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>.
[RFC8402] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <https://www.rfc-editor.org/info/rfc8403>.
[RFC8403] Geib、R.、Ed。、Filsfils、C.、Pignataro、ed。、およびN. Kumar、「スケーラブルでトポロジを認識しているMPLSデータプレーン監視システム」、RFC 8403、DOI 10.17487/RFC8403、2018年7月、<https://www.rfc-editor.org/info/rfc8403>。
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC8571] Ginsberg、L.、Ed。、Previdi、S.、Wu、Q.、Tantsura、J.、およびC. Filsfils、「BGP -Link State（BGP -LS）IGPトラフィックエンジニアリングパフォーマンスメトリック拡張の広告」、RFC 8571、DOI 10.17487/RFC8571、2019年3月、<https://www.rfc-editor.org/info/rfc8571>。
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9197] Brockners、F.、ed。、Bhandari、S.、ed。、およびT. Mizrahi、ed。、「現場操作、管理、メンテナンスのデータフィールド（IOAM）」、RFC 9197、DOI 10.17487/RFC9197、2022年5月、<https://www.rfc-editor.org/info/rfc9197>。
[STAMP-SR] Gandhi, R., Ed., Filsfils, C., Voyer, D., Chen, M., Janssens, B., and R. Foote, "Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, 1 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-03>.
[Stamp-Sr] Gandhi、R.、Ed。、Filsfils、C.、Voyer、D.、Chen、M.、Janssens、B。、およびR. Foote、「Simple Twamp（Stamp）を使用したセグメントルーティングのパフォーマンス測定ネットワーク」、作業中の進行中、インターネットドラフト、ドラフト-ITSPRING-STAMP-SRPM-03、2022年2月1日、<https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-SRPM-03>。
This appendix shows how some of the existing IPv6 OAM mechanisms can be used in an SRv6 network. It also illustrates an OAM mechanism for performing controllable and predictable flow sampling from segment endpoints. How the centralized OAM technique in [RFC8403] can be extended for SRv6 is also described in this appendix.
この付録は、既存のIPv6 OAMメカニズムの一部をSRV6ネットワークでどのように使用できるかを示しています。また、セグメントエンドポイントから制御可能で予測可能なフローサンプリングを実行するためのOAMメカニズムを示しています。[RFC8403]の集中型OAM技術をSRV6のために拡張する方法についても、この付録に記載されています。
The existing mechanism to perform the reachability checks, along the shortest path, continues to work without any modification. Any IPv6 node (SRv6-capable or non-SRv6-capable) can initiate, transit, and egress a ping packet.
最短経路に沿って、リーチ性チェックを実行する既存のメカニズムは、変更なしで機能し続けます。IPv6ノード（SRV6対応または非SRV6対応）はすべて、pingパケットを開始、通過、脱出できます。
The following subsections outline some additional use cases of ICMPv6 ping in SRv6 networks.
次のサブセクションでは、SRV6ネットワークのICMPV6 PINGのいくつかの追加のユースケースの概要を説明します。
If an SRv6-capable ingress node wants to ping an IPv6 address via an arbitrary segment list <S1, S2, S3>, it needs to initiate an ICMPv6 ping with an SR header containing the SID list <S1, S2, S3>. This is illustrated using the topology in Figure 1. The user issues a ping from node N1 to a loopback of node N5 via segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID behavior used in the example is End.X, as described in [RFC8986], but the procedure is equally applicable to any other (transit) SID type.
SRV6対応のイングレスノードが、任意のセグメントリスト<S1、S2、S3>を介してIPv6アドレスをpingしたい場合、SIDリスト<S1、S2、S3>を含むSRヘッダーを使用してICMPv6 Pingを開始する必要があります。これは、図1のトポロジを使用して示されています。ユーザーは、セグメントリストを介してノードN1からノードN5のループバックへのpingを発行します<2001：db8：2：x31 ::、2001：db8：4：x52：：>。この例で使用されているSIDの動作は、[RFC8986]で説明されているようにEnd.Xですが、手順は他の（トランジット）SIDタイプに等しく適用できます。
Figure 2 contains sample output for a ping request initiated at node N1 to a loopback address of node N5 via segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>.
図2には、セグメントリストを介してノードN5のループバックアドレスにノードN1で開始されたPINGリクエストのサンプル出力が含まれています<2001：db8：2：x31 ::、2001：db8：4：x52 ::>。
> ping 2001:db8:L:5:: via segment list 2001:db8:K:2:X31::, 2001:db8:K:4:X52::
> Ping 2001：DB8：L：5 ::セグメントリスト2001：DB8：K：2：X31 ::、2001：DB8：K：4：X52 ::
Sending 5, 100-byte ICMPv6 Echos to B5::, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625
/0.749/0.931 ms
Figure 2: Sample Ping Output at an SRv6-Capable Node
図2：srv6対応ノードでのサンプルping出力
All transit nodes process the echo request message like any other data packet carrying an SR header and hence do not require any change. Similarly, the egress node does not require any change to process the ICMPv6 echo request. For example, in the example in Figure 2:
すべてのトランジットノードは、SRヘッダーを運ぶ他のデータパケットと同様に、エコー要求メッセージを処理するため、変更は必要ありません。同様に、出力ノードは、ICMPV6エコー要求を処理するために変更を必要としません。たとえば、図2の例：
* Node N1 initiates an ICMPv6 ping packet with the SRH as follows: (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2, NH = ICMPv6)(ICMPv6 Echo Request).
* ノードN1は、次のようにSRHを使用してICMPV6 pingパケットを開始します：（2001：db8：l：1 ::、2001：db8：k：2：x31：:)（2001：db8：l：5 ::、2001：db8：k：4：x52 ::、2001：db8：k：2：x31 ::、sl = 2、nh = icmpv6）（icmpv6 echo request）。
* Node N2, which is an SRv6-capable node, performs the standard SRH processing. Specifically, it executes the End.X behavior indicated by the 2001:db8:K:2:X31:: SID and forwards the packet on link3 to node N3.
* SRV6対応ノードであるノードN2は、標準のSRH処理を実行します。具体的には、2001年：DB8：K：2：X31 :: SIDで示されたEND.X動作を実行し、Link3のパケットをノードN3に転送します。
* Node N3, which is a non-SRv6-capable node, performs the standard IPv6 processing. Specifically, it forwards the echo request based on DA 2001:db8:K:4:X52:: in the IPv6 header.
* 非SRV6対応ノードであるノードN3は、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：db8：k：4：x52 ::に基づいてエコー要求を転送します。
* Node N4, which is an SRv6-capable node, performs the standard SRH processing. Specifically, it observes the End.X behavior (2001:db8:K:4:X52::) and forwards the packet on link10 towards node N5. If 2001:db8:K:4:X52:: is a PSP SID, the penultimate node (node N4) does not, should not, and cannot differentiate between the data packets and OAM probes. Specifically, if 2001:db8:K:4:X52:: is a PSP SID, node N4 executes the SID like any other data packet with DA = 2001:db8:K:4:X52:: and removes the SRH.
* SRV6対応ノードであるノードN4は、標準のSRH処理を実行します。具体的には、end.xの動作（2001：db8：k：4：x52：:)をlink10のパケットをノードn5に転送します。2001：db8：k：4：x52 ::はPSP SIDである場合、最後から2番目のノード（ノードN4）は、データパケットとOAMプローブを区別することはできません。具体的には、2001年の場合：DB8：K：4：X52 ::はPSP SIDです。NodeN4は、DA = 2001：DB8：K：4：X52 ::を使用して他のデータパケットと同様にSIDを実行し、SRHを削除します。
* The echo request packet at node N5 arrives as an IPv6 packet with or without an SRH. If node N5 receives the packet with an SRH, it skips SRH processing (SL=0). In either case, node N5 performs the standard ICMPv6 processing on the echo request and responds with the echo reply message to node N1. The echo reply message is IP routed.
* ノードN5のエコー要求パケットは、SRHの有無にかかわらずIPv6パケットとして到着します。ノードN5がSRHでパケットを受信すると、SRH処理（SL = 0）をスキップします。どちらの場合でも、ノードN5はエコー要求で標準のICMPV6処理を実行し、ノードN1へのECHO応答メッセージで応答します。Echo ReplyメッセージはIPルーティングです。
The ping mechanism described above can also be used to perform SID reachability checks and to validate that the SID is locally programmed at the target node. This is explained in the following example. The example uses ping to an End SID, as described in [RFC8986], but the procedure is equally applicable to ping any other SID behaviors.
上記のPingメカニズムは、SIDリーチ性チェックを実行し、SIDがターゲットノードでローカルでプログラムされていることを検証するためにも使用できます。これについては、次の例で説明します。この例では、[RFC8986]で説明されているように、PingへのPingを使用しますが、手順は他のSID動作のpingに等しく適用できます。
Consider the example where the user wants to ping a remote SID 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The ICMPv6 echo request is processed at the individual nodes along the path as follows:
ユーザーがリモートSID 2001をpingしたい例を考えてみましょう：db8：k：4 ::、2001年：db8：k：2：x31 ::、ノードN1から。ICMPV6エコー要求は、次のようにパスに沿った個々のノードで処理されます。
* Node N1 initiates an ICMPv6 ping packet with the SRH as follows: (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 2001:db8:K:2:X31::; SL=1; NH=ICMPv6)(ICMPv6 Echo Request).
* ノードN1は、次のようにSRHを使用してICMPV6 pingパケットを開始します：（2001：db8：l：1 ::、2001：db8：k：2：x31：:)（2001：db8：k：4 ::、2001：db8：k：2：x31 ::; sl = 1; nh = icmpv6）（icmpv6エコー要求）。
* Node N2, which is an SRv6-capable node, performs the standard SRH processing. Specifically, it executes the End.X behavior indicated by the 2001:db8:K:2:X31:: SID on the echo request packet. If 2001:db8:K:2:X31:: is a PSP SID, node N4 executes the SID like any other data packet with DA = 2001:db8:K:2:X31:: and removes the SRH.
* SRV6対応ノードであるノードN2は、標準のSRH処理を実行します。具体的には、2001年に示されているEnd.xの動作を実行します：db8：k：2：x31 :: sid on the echo request packet。2001：db8：k：2：x31 ::はPSP SIDです。NodeN4は、DA = 2001：DB8：K：2：X31 ::を使用して他のデータパケットと同様にSIDを実行し、SRHを削除します。
* Node N3, which is a non-SRv6-capable node, performs the standard IPv6 processing. Specifically, it forwards the echo request based on DA = 2001:db8:K:4:: in the IPv6 header.
* 非SRV6対応ノードであるノードN3は、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA = 2001：DB8：K：4 ::に基づいてECHO要求を転送します。
* When node N4 receives the packet, it processes the target SID (2001:db8:K:4::).
* ノードN4がパケットを受信すると、ターゲットSID（2001：DB8：K：4：:)を処理します。
* If the target SID (2001:db8:K:4::) is not locally instantiated and does not represent a local interface, the packet is discarded
* ターゲットSID（2001：DB8：K：4：:)がローカルにインスタンス化されておらず、ローカルインターフェイスを表していない場合、パケットは破棄されます
* If the target SID (2001:db8:K:4::) is locally instantiated or represents a local interface, the node processes the Upper-Layer header. As part of the Upper-Layer header processing, node N4 responds to the ICMPv6 echo request message with an echo reply message. The echo reply message is IP routed.
* ターゲットSID（2001：DB8：K：4：:)がローカルにインスタンス化されているか、ローカルインターフェイスを表す場合、ノードは上層ヘッダーを処理します。上層層ヘッダー処理の一部として、ノードN4は、Echo Replyメッセージを使用してICMPV6エコー要求メッセージに応答します。Echo ReplyメッセージはIPルーティングです。
The existing traceroute mechanisms, along the shortest path, continue to work without any modification. Any IPv6 node (SRv6-capable or a non-SRv6-capable) can initiate, transit, and egress a traceroute probe.
最短経路に沿った既存のトレーサーメカニズムは、変更なしで動作し続けます。IPv6ノード（SRV6対応または非SRV6対応）は、トレーサープローブを開始、通過、および出力できます。
The following subsections outline some additional use cases of traceroute in SRv6 networks.
次のサブセクションでは、SRV6ネットワークのTracerouteの追加の使用ケースの概要を説明します。
If an SRv6-capable ingress node wants to traceroute to an IPv6 address via an arbitrary segment list <S1, S2, S3>, it needs to initiate a traceroute probe with an SR header containing the SID list <S1, S2, S3>. The user issues a traceroute from node N1 to a loopback of node N5 via segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID behavior used in the example is End.X, as described in [RFC8986], but the procedure is equally applicable to any other (transit) SID type. Figure 3 contains sample output for the traceroute request.
srv6対応のイングレスノードが、任意のセグメントリスト<s1、s2、s3>を介してIPv6アドレスにtracerouteする必要がある場合、SIDリスト<S1、S2、S3>を含むSRヘッダーを使用してトレーサーアウトプローブを開始する必要があります。ユーザーは、セグメントリストを介してノードn1からノードN5のループバックへのトレーサーを発行します<2001：db8：k：2：x31 ::、2001：db8：k：4：x52 ::>。この例で使用されているSIDの動作は、[RFC8986]で説明されているようにEnd.Xですが、手順は他の（トランジット）SIDタイプに等しく適用できます。図3には、Tracerouteリクエストのサンプル出力が含まれています。
> traceroute 2001:db8:L:5:: via segment list 2001:db8:K:2:X31::, 2001:db8:K:4:X52::
> Traceroute 2001：DB8：L：5 ::セグメントリスト2001：DB8：K：2：X31 ::、2001：DB8：K：4：X52 ::
Tracing the route to 2001:db8:L:5:: 1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec DA: 2001:db8:K:2:X31::, SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2) 2 2001:db8:3:2:31:: 0.721 msec 0.810 msec 0.795 msec DA: 2001:db8:K:4:X52::, SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 3 2001:db8:4:3::41:: 0.921 msec 0.816 msec 0.759 msec DA: 2001:db8:K:4:X52::, SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 4 2001:db8:5:4::52:: 0.879 msec 0.916 msec 1.024 msec DA: 2001:db8:L:5::
2001年までのルートのトレース：db8：l：5 :: 1 2001：db8：2：1：21：21 :: 0.512 msec 0.425 msec 0.374 msec DA：2001：db8：k：2：x31 ::、srh：（2001：（2001：」DB8：L：5 ::、2001：DB8：K：4：X52 ::、2001：DB8：K：2：X31 ::、SL = 2）2 2001：DB8：3：2：31 :: 0.721ミリ秒0.810 MSEC 0.795 MSEC DA：2001：DB8：K：4：X52 ::、SRH：（2001：DB8：L：5 ::、2001：DB8：K：4：X52 ::、2001：DB8：K：2：x31 ::、SL = 1）3 2001：DB8：4：3 :: 41 :: 0.921 MSEC 0.816 MSEC 0.759 MSEC DA：2001：DB8：K：4：X52 ::、SRH：（2001：DB8：L L：5 ::、2001：db8：k：4：x52 ::、2001：db8：k：2：x31 ::、sl = 1）4 2001：db8：5：4 :: 52 :: 0.879ミリ秒0.916ミリ秒1.024 MSEC DA：2001：DB8：L：5 ::
Figure 3: Sample Traceroute Output at an SRv6-Capable Node
図3：SRV6対応ノードでのトレーサーアウト出力をサンプル
In the sample traceroute output, the information displayed at each hop is obtained using the contents of the "Time Exceeded" or "Destination Unreachable" ICMPv6 responses. These ICMPv6 responses are IP routed.
サンプルTraceroute出力では、各ホップで表示される情報は、「時間を超えた時間」または「宛先の到達不可能」ICMPV6応答の内容を使用して取得されます。これらのICMPV6応答はIPルーティングです。
In the sample traceroute output, the information for link3 is returned by node N3, which is a non-SRv6-capable node. Nonetheless, the ingress node is able to display SR header contents as the packet travels through the non-SRv6-capable node. This is because the "Time Exceeded" ICMPv6 message can contain as much of the invoking packet as possible without the ICMPv6 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is included in these ICMPv6 messages initiated by the non-SRv6-capable transit nodes that are not running SRv6 software. Specifically, a node generating an ICMPv6 message containing a copy of the invoking packet does not need to understand the extension header(s) in the invoking packet.
サンプルTraceroute出力では、Link3の情報はノードN3によって返されます。これは非SRV6対応ノードです。それにもかかわらず、イングレスノードは、パケットが非SRV6対応ノードを介して移動するときにSRヘッダーの内容を表示できます。これは、「ICMPv6メッセージが最小IPv6 MTU [RFC4443]を超えるICMPv6パケットがなければ、可能な限り多くの呼び出しパケットを含めることができるためです。SRヘッダーは、SRV6ソフトウェアを実行していない非SRV6対応トランジットノードによって開始されたこれらのICMPV6メッセージに含まれています。具体的には、呼び出しパケットのコピーを含むICMPV6メッセージを生成するノードは、呼び出しパケットの拡張ヘッダーを理解する必要はありません。
The segment list information returned for the first hop is returned by node N2, which is an SRv6-capable node. Just like for the second hop, the ingress node is able to display SR header contents for the first hop.
最初のホップで返されるセグメントリスト情報は、SRV6対応ノードであるノードN2によって返されます。2番目のホップと同じように、Ingressノードは最初のホップにSRヘッダーの内容を表示できます。
There is no difference in processing of the traceroute probe at an SRv6-capable and a non-SRv6-capable node. Similarly, both SRv6-capable and non-SRv6-capable nodes may use the address of the interface on which probe was received as the source address in the ICMPv6 response. ICMPv6 extensions defined in [RFC5837] can be used to display information about the IP interface through which the datagram would have been forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded, the IP interface upon which the datagram arrived, and the sub-IP component of an IP interface upon which the datagram arrived.
SRV6対応および非SRV6対応ノードでのTracerouteプローブの処理に違いはありません。同様に、SRV6対応および非SRV6対応ノードの両方が、ICMPV6応答のソースアドレスとしてプローブが受信されたインターフェイスのアドレスを使用する場合があります。[RFC5837]で定義されているICMPV6拡張機能を使用して、データグラムが転送された場合に転送されたIPインターフェイスに関する情報を表示できます。到着し、データグラムが到着したIPインターフェイスのサブIPコンポーネントが到着しました。
The IP address of the interface on which the traceroute probe was received is useful. This information can also be used to verify if SIDs 2001:db8:K:2:X31:: and 2001:db8:K:4:X52:: are executed correctly by nodes N2 and N4, respectively. Specifically, the information displayed for the second hop contains the incoming interface address 2001:db8:2:3:31:: at node N3. This matches the expected interface bound to End.X behavior 2001:db8:K:2:X31:: (link3). Similarly, the information displayed for the fourth hop contains the incoming interface address 2001:db8:4:5::52:: at node N5. This matches the expected interface bound to the End.X behavior 2001:db8:K:4:X52:: (link10).
Tracerouteプローブが受信されたインターフェイスのIPアドレスは有用です。この情報は、SIDS 2001：DB8：K：2：X31 ::および2001：DB8：K：4：X52 ::それぞれノードN2とN4によって正しく実行されるかどうかを検証するためにも使用できます。具体的には、2番目のホップに表示される情報には、Node N3の着信インターフェイスアドレス2001：DB8：2：3：31 ::が含まれています。これは、end.x行動2001にバインドされた予想されるインターフェイスと一致します：db8：k：2：x31 ::（ link3）。同様に、4番目のホップに表示される情報には、Node N5での入力インターフェイスアドレス2001：DB8：4：5 :: 52 ::が含まれています。これは、End.x Behavior 2001：DB8：K：4：X52 ::（LINK10）に結合した予想されるインターフェイスと一致します。
The mechanism to traceroute an IPv6 address via a segment list described in the previous section can also be used to traceroute a remote SID behavior, as explained in the following example. The example uses traceroute to an End SID, as described in [RFC8986], but the procedure is equally applicable to tracerouting any other SID behaviors.
前のセクションで説明したセグメントリストを介してIPv6アドレスをトレーサーするメカニズムは、次の例で説明されているように、リモートSIDの動作をトレーサーするためにも使用できます。この例では、[RFC8986]で説明されているように、TracerouteをEnd SIDに使用しますが、手順は他のSID動作のトレーサーに等しく適用できます。
Please note that traceroute to a SID is exemplified using UDP probes. However, the procedure is equally applicable to other implementations of traceroute mechanism. The UDP encoded message to traceroute a SID would use the UDP ports assigned by IANA for "traceroute use".
SIDへのTracerouteは、UDPプローブを使用して例示されていることに注意してください。ただし、この手順は、Tracerouteメカニズムの他の実装に等しく適用できます。sidをtracerouteするためのUDPエンコードメッセージは、「traceroute使用」のためにIANAが割り当てたUDPポートを使用します。
Consider the example where the user wants to traceroute a remote SID 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The traceroute probe is processed at the individual nodes along the path as follows:
ユーザーがリモートSID 2001をトレーサーしたい例を考えてみましょう：db8：k：4 ::、2001年：db8：k：2：x31 ::、ノードN1から。Tracerouteプローブは、次のようにパスに沿った個々のノードで処理されます。
* Node N1 initiates a traceroute probe packet as follows (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 2001:db8:K:2:X31::; SL=1; NH=UDP)(Traceroute probe). The first traceroute probe is sent with the hop-count value set to 1. The hop-count value is incremented by 1 for each subsequent traceroute probe.
* ノードN1は、次のようにトレーサーアウトプローブパケットを開始します（2001：DB8：L：1 ::、2001：DB8：K：2：X31：:)（2001：DB8：K：4 ::、2001：DB8：K：2：x31 ::; sl = 1; nh = udp）（tracerouteプローブ）。最初のTracerouteプローブは、ホップカウント値を1に設定して送信されます。ホップカウント値は、その後のトレーサープローブごとに1個ずつ増加します。
* When node N2 receives the packet with hop-count = 1, it processes the hop-count expiry. Specifically, node N2 responds with the ICMPv6 message with type "Time Exceeded" and code "hop limit exceeded in transit". The ICMPv6 response is IP routed.
* ノードn2がホップカウント= 1でパケットを受信すると、ホップカウントの有効期限が処理されます。具体的には、Node N2はICMPV6メッセージで「時間を超えた」タイプで応答し、「輸送中にコードホップ制限」を超えて応答します。ICMPV6応答はIPルーティングです。
* When node N2 receives the packet with hop-count > 1, it performs the standard SRH processing. Specifically, it executes the End.X behavior indicated by the 2001:db8:K:2:X31:: SID on the traceroute probe. If 2001:db8:K:2:X31:: is a PSP SID, node N2 executes the SID like any other data packet with DA = 2001:db8:K:2:X31:: and removes the SRH.
* ノードN2がホップカウント> 1でパケットを受信すると、標準のSRH処理が実行されます。具体的には、2001年に示されているEnd.xの動作を実行します：DB8：K：2：X31 :: TRACEROUTEプローブのSID。2001：db8：k：2：x31 ::はPSP SIDです。NodeN2は、DA = 2001：DB8：K：2：X31 ::を使用して他のデータパケットと同様にSIDを実行し、SRHを削除します。
* When node N3, which is a non-SRv6-capable node, receives the packet with hop-count = 1, it processes the hop-count expiry. Specifically, node N3 responds with the ICMPv6 message with type "Time Exceeded" and code "Hop limit exceeded in transit". The ICMPv6 response is IP routed.
* 非SRV6対応ノードであるノードN3がホップカウント= 1でパケットを受信すると、ホップカウントの有効期限を処理します。具体的には、Node N3はICMPV6メッセージで「時間を超えた」タイプで応答し、「輸送中にコードホップ制限」を超えて応答します。ICMPV6応答はIPルーティングです。
* When node N3, which is a non-SRv6-capable node, receives the packet with hop-count > 1, it performs the standard IPv6 processing. Specifically, it forwards the traceroute probe based on DA 2001:db8:K:4:: in the IPv6 header.
* 非SRV6対応ノードであるノードN3がホップカウント> 1のパケットを受信すると、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：DB8：K：4 ::に基づいてTracerouteプローブを転送します。
* When node N4 receives the packet with DA set to the local SID 2001:db8:K:4::, it processes the End SID.
* Node N4がローカルSID 2001に設定されたDAセットでパケットを受信すると、DB8：K：4 ::、END SIDを処理します。
* If the target SID (2001:db8:K:4::) is not locally instantiated and does not represent a local interface, the packet is discarded.
* ターゲットSID（2001：DB8：K：4：:)がローカルにインスタンス化されておらず、ローカルインターフェイスを表していない場合、パケットは破棄されます。
* If the target SID (2001:db8:K:4::) is locally instantiated or represents a local interface, the node processes the Upper-Layer header. As part of the Upper-Layer header processing, node N4 responds with the ICMPv6 message with type "Destination Unreachable" and code "Port Unreachable". The ICMPv6 response is IP routed.
* ターゲットSID（2001：DB8：K：4：:)がローカルにインスタンス化されているか、ローカルインターフェイスを表す場合、ノードは上層ヘッダーを処理します。上層層ヘッダー処理の一部として、ノードN4は、タイプ「宛先なし」とコード「ポートが到達不可能」でICMPV6メッセージで応答します。ICMPV6応答はIPルーティングです。
Figure 4 displays a sample traceroute output for this example.
図4は、この例のサンプルトレーサーアウト出力を示しています。
> traceroute 2001:db8:K:4:X52:: via segment list 2001:db8:K:2:X31::
> Traceroute 2001：DB8：K：4：X52 ::セグメントリスト2001：DB8：K：2：X31 ::
Tracing the route to SID 2001:db8:K:4:X52::
1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec
DA: 2001:db8:K:2:X31::,
SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=1)
2 2001:db8:3:2:21:: 0.721 msec 0.810 msec 0.795 msec
DA: 2001:db8:K:4:X52::,
SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0)
3 2001:db8:4:3:41:: 0.921 msec 0.816 msec 0.759 msec
DA: 2001:db8:K:4:X52::,
SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0)
Figure 4: Sample Output for Hop-by-Hop Traceroute to a SID
図4：SIDへのホップバイホップトレーサーのサンプル出力
This section illustrates a hybrid OAM mechanism using the O-flag. Without loss of the generality, the illustration assumes node N100 is a centralized controller.
このセクションでは、O-Flagを使用したハイブリッドOAMメカニズムを示しています。一般性を失うことなく、イラストはノードN100が集中コントローラーであると想定しています。
This illustration is different from the "in situ OAM" defined in [RFC9197]. This is because in situ OAM records operational and telemetry information in the packet as the packet traverses a path between two points in the network [RFC9197]. The illustration in this subsection does not require the recording of OAM data in the packet.
この図は、[RFC9197]で定義されている「in situ OAM」とは異なります。これは、パケットがネットワーク内の2つのポイント間のパスを横断するため、パケットに操作およびテレメトリ情報を記録するため、これはこれがないためです[RFC9197]。このサブセクションの図は、パケット内のOAMデータの記録を必要としません。
The illustration does not assume any formats for exporting the data elements or the data elements that need to be exported. The illustration assumes system clocks among all nodes in the SR domain are synchronized.
この図は、データ要素またはエクスポートする必要があるデータ要素をエクスポートするための形式を想定していません。この図は、SRドメイン内のすべてのノード間のシステムクロックが同期されていることを想定しています。
Consider the example where the user wants to monitor sampled IPv4 VPN 999 traffic going from CE1 to CE2 via a low-latency SR Policy P installed at node N1. To exercise a low-latency path, the SR Policy P forces the packet via segments 2001:db8:K:2:X31:: and 2001:db8:K:4:X52::. The VPN SID at node N7 associated with VPN 999 is 2001:db8:K:7:DT999::. 2001:db8:K:7:DT999:: is a USP SID. Nodes N1, N4, and N7 are capable of processing the O-flag, but node N2 is not capable of processing the O-flag. Node N100 is the centralized controller capable of processing and correlating the copy of the packets sent from nodes N1, N4, and N7. Node N100 is aware of O-flag processing capabilities. Node N100, with help from nodes N1, N4, and N7, implements a hybrid OAM mechanism using the O-flag as follows:
ユーザーが、ノードN1にインストールされた低遅延SRポリシーPを介してCE1からCE2に移動するサンプルされたIPv4 VPN 999トラフィックを監視したい例を考えてみましょう。低遅延パスを行使するために、SRポリシーPはセグメント2001を介してパケットを強制します。VPN 999に関連付けられたノードN7のVPN SIDは2001年です：DB8：K：7：DT999 ::。2001：DB8：K：7：DT999 ::はUSP SIDです。ノードN1、N4、およびN7はO-Flagを処理できますが、ノードN2はO-Flagを処理できません。ノードN100は、ノードN1、N4、およびN7から送信されたパケットのコピーを処理および相関させることができる集中コントローラーです。ノードN100は、O-FLAG処理機能を認識しています。ノードN1、N4、およびN7のヘルプを備えたノードN100は、次のようにO-Flagを使用してハイブリッドOAMメカニズムを実装します。
* A packet P1 is sent from CE1 to node N1. The packet is:
* パケットP1はCE1からノードN1に送信されます。パケットは次のとおりです。
P1: (IPv4 header)(payload)
P1 ：（ IPv4ヘッダー）（ペイロード）
* Node N1 steers packet P1 through the SR Policy P. Based on local configuration, node N1 also implements logic to sample traffic steered through SR Policy P for hybrid OAM purposes. Specification for the sampling logic is beyond the scope of this document. Consider the case where packet P1 is classified as a packet to be monitored via the hybrid OAM. Node N1 sets the O-flag during the encapsulation required by SR Policy P. As part of setting the O-flag, node N1 also sends a timestamped copy of packet P1 to a local OAM process. The packet is:
* Node N1 Steers Packet P1を介してP1を介してローカル構成に基づいて、ノードN1は、ハイブリッドOAMの目的でSRポリシーPを介して操縦されたトラフィックをサンプリングするためのロジックも実装しています。サンプリングロジックの仕様は、このドキュメントの範囲を超えています。パケットP1がハイブリッドOAMを介して監視されるパケットとして分類される場合を検討してください。Node N1は、SRポリシーPで要求されるカプセル化中にO-Flagを設定します。O-Flagの設定の一環として、ノードN1はパケットP1のタイムスタンプコピーをローカルOAMプロセスに送信します。パケットは次のとおりです。
P1: (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:7:DT999::,
2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=2; O-flag=1;
NH=IPv4)(IPv4 header)(payload)
The local OAM process sends a full or partial copy of packet P1 to node N100. The OAM process includes the recorded timestamp, additional OAM information (like incoming and outgoing interface), and any applicable metadata. Node N1 forwards the original packet towards the next segment 2001:db8:K:2:X31::.
ローカルOAMプロセスは、パケットP1の完全または部分コピーをノードN100に送信します。OAMプロセスには、記録されたタイムスタンプ、追加のOAM情報（着信や発信インターフェイスなど）、および該当するメタデータが含まれます。ノードN1は、元のパケットを次のセグメント2001に向けて転送します：db8：k：2：x31 ::。
* When node N2 receives the packet with the O-flag set, it ignores the O-flag. This is because node N2 is not capable of processing the O-flag. Node N2 performs the standard SRv6 SID and SRH processing. Specifically, it executes the End.X behavior [RFC8986] indicated by the 2001:db8:K:2:X31:: SID and forwards packet P1 over link3 towards node N3. The packet is:
* Node N2がO-Flagセットでパケットを受信すると、O-Flagは無視されます。これは、ノードN2がO-Flagを処理できないためです。ノードN2は、標準のSRV6 SIDおよびSRH処理を実行します。具体的には、2001：db8：k：2：x31 :: sid and forwards packet p1をlink3にノードN3に転送することを示すend.xの動作[RFC8986]を実行します。パケットは次のとおりです。
P1: (2001:db8:L:1::, 2001:db8:K:4:X52::) (2001:db8:K:7:DT999::,
2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=1; O-flag=1;
NH=IPv4)(IPv4 header)(payload)
* When node N3, which is a non-SRv6-capable node, receives packet P1, it performs the standard IPv6 processing. Specifically, it forwards packet P1 based on DA 2001:db8:K:4:X52:: in the IPv6 header.
* 非SRV6対応ノードであるノードN3がパケットP1を受信すると、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：db8：k：4：x52 ::に基づいてパケットP1を転送します。
* When node N4 receives packet P1, it processes the O-flag. The packet is:
* ノードN4がパケットP1を受信すると、O-Flagを処理します。パケットは次のとおりです。
P1: (2001:db8:L:1::, 2001:db8:K:4:X52::) (2001:db8:K:7:DT999::,
2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=1; O-flag=1;
NH=IPv4)(IPv4 header)(payload)
As part of processing the O-flag, it sends a timestamped copy of the packet to a local OAM process. Based on local configuration, the local OAM process sends a full or partial copy of packet P1 to node N100. The OAM process includes the recorded timestamp, additional OAM information (like incoming and outgoing interface, etc.), and any applicable metadata. Node N4 performs the standard SRv6 SID and SRH processing on the original packet P1. Specifically, it executes the End.X behavior indicated by the 2001:db8:K:4:X52:: SID and forwards packet P1 over link10 towards node N5. The packet is:
O-Flagの処理の一環として、パケットのタイムスタンプ付きコピーをローカルOAMプロセスに送信します。ローカル構成に基づいて、ローカルOAMプロセスは、パケットP1の完全または部分コピーをノードN100に送信します。OAMプロセスには、記録されたタイムスタンプ、追加のOAM情報（着信や発信インターフェイスなど）、および該当するメタデータが含まれます。ノードN4は、元のパケットP1で標準のSRV6 SIDおよびSRH処理を実行します。具体的には、2001年に示されているend.xの動作を実行します：db8：k：4：x52 :: sid and forwards packet p1をlink10越えてノードn5に向けます。パケットは次のとおりです。
P1: (2001:db8:L:1::, 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::,
2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0; O-flag=1;
NH=IPv4)(IPv4 header)(payload)
* When node N5, which is a non-SRv6-capable node, receives packet P1, it performs the standard IPv6 processing. Specifically, it forwards the packet based on DA 2001:db8:K:7:DT999:: in the IPv6 header.
* 非SRV6対応ノードであるノードN5がパケットP1を受信すると、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：db8：k：7：dt999 ::に基づいてパケットを転送します。
* When node N7 receives packet P1, it processes the O-flag. The packet is:
* ノードN7がパケットP1を受信すると、O-Flagを処理します。パケットは次のとおりです。
P1: (2001:db8:L:1::, 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::,
2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0; O-flag=1;
NH=IPv4)(IPv4 header)(payload)
As part of processing the O-flag, it sends a timestamped copy of the packet to a local OAM process. The local OAM process sends a full or partial copy of packet P1 to node N100. The OAM process includes the recorded timestamp, additional OAM information (like incoming and outgoing interface, etc.), and any applicable metadata. Node N7 performs the standard SRv6 SID and SRH processing on the original packet P1. Specifically, it executes the VPN SID indicated by the 2001:db8:K:7:DT999:: SID and, based on lookup in table 100, forwards packet P1 towards CE2. The packet is:
O-Flagの処理の一環として、パケットのタイムスタンプ付きコピーをローカルOAMプロセスに送信します。ローカルOAMプロセスは、パケットP1の完全または部分コピーをノードN100に送信します。OAMプロセスには、記録されたタイムスタンプ、追加のOAM情報（着信や発信インターフェイスなど）、および該当するメタデータが含まれます。ノードN7は、元のパケットP1で標準のSRV6 SIDおよびSRH処理を実行します。具体的には、2001年に示されているVPN SIDを実行します：DB8：K：7：DT999 :: SID、および表100のルックアップに基づいて、CE2にパケットP1を転送します。パケットは次のとおりです。
P1: (IPv4 header)(payload)
P1 ：（ IPv4ヘッダー）（ペイロード）
* Node N100 processes and correlates the copy of the packets sent from nodes N1, N4, and N7 to find segment-by-segment delays and provide other hybrid OAM information related to packet P1. For segment-by-segment delay computation, it is assumed that clocks are synchronized across the SR domain.
* ノードN100プロセスと相関して、ノードN1、N4、およびN7から送信されたパケットのコピーを相関させて、セグメントごとの遅延を見つけ、パケットP1に関連する他のハイブリッドOAM情報を提供します。セグメントごとの遅延計算の場合、クロックはSRドメイン全体で同期されると想定されています。
* The process continues for any other sampled packets.
* このプロセスは、他のサンプリングされたパケットについて続きます。
In the recent past, network operators demonstrated interest in performing network OAM functions in a centralized manner. [RFC8403] describes such a centralized OAM mechanism. Specifically, [RFC8403] describes a procedure that can be used to perform path continuity checks between any nodes within an SR domain from a centralized monitoring system. However, while [RFC8403] focuses on SR networks with MPLS data plane, this document describes how the concept can be used to perform path monitoring in an SRv6 network from a centralized controller.
最近では、ネットワークオペレーターは、集中的にネットワークOAM機能を実行することに関心を示していました。[RFC8403]は、このような集中化されたOAMメカニズムを説明しています。具体的には、[RFC8403]は、集中監視システムからSRドメイン内のノード間でパス連続性チェックを実行するために使用できる手順を説明します。ただし、[RFC8403]はMPLSデータプレーンを使用したSRネットワークに焦点を当てていますが、このドキュメントでは、概念を使用して集中コントローラーからSRV6ネットワークでパス監視を実行する方法について説明します。
In the reference topology in Figure 1, node N100 uses an IGP protocol like OSPF or IS-IS to get a view of the topology within the IGP domain. Node N100 can also use BGP-LS to get the complete view of an inter-domain topology. The controller leverages the visibility of the topology to monitor the paths between the various endpoints.
図1の参照トポロジでは、ノードN100はOSPFまたはIS-I-ISのIGPプロトコルを使用して、IGPドメイン内のトポロジーのビューを取得します。ノードN100は、BGP-LSを使用して、ドメイン間トポロジーの完全なビューを取得することもできます。コントローラーは、トポロジの可視性を活用して、さまざまなエンドポイント間のパスを監視します。
Node N100 advertises an End SID [RFC8986] 2001:db8:K:100:1::. To monitor any arbitrary SRv6 paths, the controller can create a loopback probe that originates and terminates on node N100. To distinguish between a failure in the monitored path and loss of connectivity between the controller and the network, node N100 runs a suitable mechanism to monitor its connectivity to the monitored network.
ノードN100は、sid [rfc8986] 2001：db8：k：100：1 ::を宣伝します。任意のSRV6パスを監視するために、コントローラーはノードN100で発生および終了するループバックプローブを作成できます。監視されたパスでの障害とコントローラーとネットワーク間の接続の損失を区別するために、ノードN100は監視されたネットワークへの接続を監視するための適切なメカニズムを実行します。
The following example illustrates loopback probes in which node N100 needs to verify a segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>:
次の例は、ノードN100がセグメントリストを検証する必要があるループバックプローブ<2001：db8：2：x31 ::、2001：db8：k：4：x52 ::>：
* Node N100 generates an OAM packet (2001:db8:L:100::, 2001:db8:K:2:X31::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2)(OAM Payload). The controller routes the probe packet towards the first segment, which is 2001:db8:K:2:X31::.
* ノードN100はOAMパケットを生成します（2001：DB8：L：100 ::、2001：DB8：K：2：X31 ::）（2001：DB8：K：100：1 ::、2001：DB8：K：4：x52 ::、2001：db8：k：2：x31 ::、sl = 2）（OAMペイロード）。コントローラーは、プローブパケットを最初のセグメント、つまり2001：db8：k：2：x31 ::に向けてルーティングします。
* Node N2 executes the End.X behavior indicated by the 2001:db8:K:2:X31:: SID and forwards the packet (2001:db8:L:100::, 2001:db8:K:4:X52::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1)(OAM Payload) on link3 to node N3.
* Node N2は、2001年に示されているEnd.xの動作を実行します：DB8：K：2：X31 :: SIDとPACKETを転送（2001：DB8：L：100 ::、2001：DB8：4：X52：:)（2001：db8：k：100：1 ::、2001：db8：k：4：x52 ::、2001：db8：k：2：x31 ::、sl = 1）（oam payload）（oamペイロード）ノードn3へ。
* Node N3, which is a non-SRv6-capable node, performs the standard IPv6 processing. Specifically, it forwards the packet based on DA 2001:db8:K:4:X52:: in the IPv6 header.
* 非SRV6対応ノードであるノードN3は、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：db8：k：4：x52 ::に基づいてパケットを転送します。
* Node N4 executes the End.X behavior indicated by the 2001:db8:K:4:X52:: SID and forwards the packet (2001:db8:L:100::, 2001:db8:K:100:1::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=0)(OAM Payload) on link10 to node N5.
* Node N4は、2001年に示されているEnd.xの動作を実行します：DB8：K：4：X52 :: SIDとPACKETを転送（2001：DB8：L：100 ::、2001：DB8：K：100：1：:)（2001：db8：k：100：1 ::、2001：db8：k：4：x52 ::、2001：db8：k：2：x31 ::、sl = 0）（oam payload）on link10 on node n5。
* Node N5, which is a non-SRv6-capable node, performs the standard IPv6 processing. Specifically, it forwards the packet based on DA 2001:db8:K:100:1:: in the IPv6 header.
* 非SRV6対応ノードであるノードN5は、標準のIPv6処理を実行します。具体的には、IPv6ヘッダーでDA 2001：db8：k：100：1 ::に基づいてパケットを転送します。
* Node N100 executes the standard SRv6 END behavior. It decapsulates the header and consumes the probe for OAM processing. The information in the OAM payload is used to detect missing probes, round-trip delay, etc.
* ノードN100は、標準のSRV6エンド動作を実行します。ヘッダーを脱カプセル化し、OAM処理のプローブを消費します。OAMペイロードの情報は、欠落しているプローブ、往復遅延などを検出するために使用されます。
The OAM payload type or the information carried in the OAM probe is a local implementation decision at the controller and is outside the scope of this document.
OAMペイロードタイプまたはOAMプローブに掲載された情報は、コントローラーでのローカル実装決定であり、このドキュメントの範囲外です。
Acknowledgements
謝辞
The authors would like to thank Joel M. Halpern, Greg Mirsky, Bob Hinden, Loa Andersson, Gaurav Naik, Ketan Talaulikar, and Haoyu Song for their review comments.
著者は、ジョエル・M・ハルパーン、グレッグ・ミルスキー、ボブ・ヒンデン、ロア・アンダーソン、ガウラヴ・ナイク、ケタン・タラリカー、ハイウのレビューコメントに感謝したいと思います。
Contributors
貢献者
The following people contributed to this document:
次の人々がこの文書に貢献しました。
Robert Raszuk Bloomberg LP Email: robert@raszuk.net
Robert Raszuk Bloomberg LPメール：robert@raszuk.net
John Leddy Individual Email: john@leddy.net
John Leddy個人メール：john@leddy.net
Gaurav Dawra LinkedIn Email: gdawra.ietf@gmail.com
Gaurav Dawra LinkedInメール：gdawra.ietf@gmail.com
Bart Peirens Proximus Email: bart.peirens@proximus.com
Bart Peirens Proximusメール：bart.peirens@proximus.com
Nagendra Kumar Cisco Systems, Inc. Email: naikumar@cisco.com
Nagendra Kumar Cisco Systems、Inc。電子メール：naikumar@cisco.com
Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com
Carlos Pignataro Cisco Systems、Inc。電子メール：cpignata@cisco.com
Rakesh Gandhi Cisco Systems, Inc. Email: rgandhi@cisco.com
Rakesh Gandhi Cisco Systems、Inc。電子メール：rgandhi@cisco.com
Frank Brockners Cisco Systems, Inc. Email: fbrockne@cisco.com
Frank Brockners Cisco Systems、Inc。メール：fbrockne@cisco.com
Darren Dukes Cisco Systems, Inc. Email: ddukes@cisco.com
Darren Dukes Cisco Systems、Inc。電子メール：ddukes@cisco.com
Cheng Li Huawei Email: chengli13@huawei.com
cheng li huaweiメール：chengli13@huawei.com
Faisal Iqbal Individual Email: faisal.ietf@gmail.com
faisal iqbal個人メール：faisal.ietf@gmail.com
Authors' Addresses
著者のアドレス
Zafar Ali Cisco Systems Email: zali@cisco.com
Zafar Ali Cisco Systems Email：zali@cisco.com
Clarence Filsfils Cisco Systems Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems Email：cfilsfil@cisco.com
Satoru Matsushima Softbank Email: satoru.matsushima@g.softbank.co.jp
Satoru Matsushima SoftBankメール：satoru.matsushima@g.softbank.co.jp
Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca
Daniel Voyer Bell Canadaメール：daniel.voyer@bell.ca
Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com
Mach（Guoyi）Chen Huaweiメール：mach.chen@huawei.com