[要約] RFC 8403は、スケーラブルでトポロジに意識したMPLSデータプレーンのモニタリングシステムに関するものです。その目的は、MPLSネットワークのトラフィックモニタリングを改善し、ネットワークのパフォーマンスやトラブルシューティングを支援することです。
Internet Engineering Task Force (IETF) R. Geib, Ed.
Request for Comments: 8403 Deutsche Telekom
Category: Informational C. Filsfils
ISSN: 2070-1721 C. Pignataro, Ed.
N. Kumar
Cisco Systems, Inc.
July 2018
A Scalable and Topology-Aware MPLS Data-Plane Monitoring System
スケーラブルでトポロジーを意識したMPLSデータプレーンモニタリングシステム
Abstract
概要
This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.
このドキュメントでは、MPLSパスモニタリングシステムの機能と関連する使用例について説明します。セグメントベースのルーティングにより、単一ドメインに属するパスの完全なセットのデータプレーンの活性を監視するスケーラブルでシンプルな方法が可能になります。 MPLSモニタリングシステムは、従来のMPLS pingおよびラベルスイッチドパス（LSP）トレースに非常に補完的な方法で機能を追加します。 MPLSトポロジ認識は、新しいOAM機能を有効にしながら、運用、管理、および保守（OAM）測定の管理およびコントロールプレーンの関与を減らします。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8403.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8403で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6
4. Illustration of an SR-Based Path Monitoring Use Case . . . . 8
4.1. Use Case 1: LSP Data-Plane Monitoring . . . . . . . . . . 8
4.2. Use Case 2: Monitoring a Remote Bundle . . . . . . . . . 11
4.3. Use Case 3: Fault Localization . . . . . . . . . . . . . 12
5. Path Trace and Failure Notification . . . . . . . . . . . . . 12
6. Applying SR to Monitoring LSPs That Are Not SR Based (LDP and
Possibly RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . 13
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 14
8. Connectivity Verification Using PMS . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Network operators need to be able to monitor the forwarding paths used to transport user packets. Monitoring packets are expected to be forwarded in the data plane in a similar way to user packets. Segment Routing (SR) enables forwarding of packets along predefined paths and segments; thus, an SR monitoring packet can stay in the data plane while passing along one or more segments to be monitored.
ネットワークオペレーターは、ユーザーパケットの転送に使用される転送パスを監視できる必要があります。監視パケットは、ユーザーパケットと同様の方法でデータプレーンに転送されることが期待されています。セグメントルーティング（SR）により、事前定義されたパスとセグメントに沿ってパケットを転送できます。したがって、SR監視パケットは、監視対象の1つ以上のセグメントを通過する間、データプレーンに留まることができます。
This document describes a system as a functional component called (MPLS) Path Monitoring System or PMS. The PMS uses capabilities for MPLS data-plane path monitoring. The use cases introduced here are limited to a single Interior Gateway Protocol (IGP) MPLS domain. The use cases of this document refer to the PMS realized as a separate node. Although many use cases depict the PMS as a physical node, no assumption should be made, and the node could be virtual. This system is defined as a functional component abstracted to have many realizations. The terms "PMS" and "system" are used interchangeably here.
このドキュメントでは、システムを（MPLS）パスモニタリングシステムまたはPMSと呼ばれる機能コンポーネントとして説明します。 PMSは、MPLSデータプレーンパスモニタリングの機能を使用します。ここで紹介する使用例は、単一の内部ゲートウェイプロトコル（IGP）MPLSドメインに限定されています。このドキュメントの使用例では、別のノードとして実現されたPMSを参照しています。多くのユースケースではPMSを物理ノードとして示していますが、想定する必要はなく、ノードは仮想である可能性があります。このシステムは、多くの実現を持つように抽象化された機能コンポーネントとして定義されます。 「PMS」と「システム」という用語は、ここでは互換的に使用されます。
The system applies to the monitoring of non-SR LSPs like Label Distribution Protocol (LDP) as well as to the monitoring of SR LSPs (Section 7 offers some more information). As compared to non-SR approaches, SR is expected to simplify such a monitoring system by enabling MPLS topology detection based on IGP-signaled segments. The MPLS topology should be detected and correlated with the IGP topology, which is also detected by IGP signaling. Thus, a centralized and MPLS-topology-aware monitoring unit can be realized in an SR domain. This topology awareness can be used for Operation, Administration, and Maintenance (OAM) purposes as described by this document.
このシステムは、ラベル配布プロトコル（LDP）のような非SR LSPの監視と、SR LSPの監視に適用されます（セクション7に詳細が記載されています）。 SR以外のアプローチと比較して、SRはIGPシグナリングセグメントに基づくMPLSトポロジ検出を有効にすることにより、このような監視システムを簡素化することが期待されています。 MPLSトポロジは検出され、IGPトポロジと相関する必要があります。IGPトポロジは、IGPシグナリングによっても検出されます。したがって、集中型のMPLSトポロジ対応の監視ユニットをSRドメインで実現できます。このトポロジ認識は、このドキュメントで説明されているように、運用、管理、および保守（OAM）の目的で使用できます。
Benefits offered by the system:
システムが提供する利点：
o The ability to set up an SR-domain-wide centralized connectivity validation. Many operators of large networks regard a centralized monitoring system as useful.
o SRドメイン全体の一元化された接続検証をセットアップする機能。大規模ネットワークの多くの事業者は、集中型監視システムが有用であると考えています。
o The MPLS ping (or continuity check) packets never leave the MPLS user data plane.
o MPLS ping（または継続性チェック）パケットは、MPLSユーザーデータプレーンを離れることはありません。
o SR allows the transport of MPLS path trace or connectivity validation packets for every LSP to all nodes of an SR domain. This use case doesn't describe new path-trace features. The system described here allows for the set up of an SR-domain-wide centralized connectivity validation, which is useful in large network operator domains.
o SRでは、すべてのLSPのMPLSパストレースまたは接続検証パケットをSRドメインのすべてのノードに転送できます。この使用例では、新しいパストレース機能については説明していません。ここで説明するシステムでは、SRドメイン全体の集中接続検証をセットアップできます。これは、大規模なネットワークオペレータードメインで役立ちます。
o The system sending the monitoring packet is also receiving it. The payload of the monitoring packet may be chosen freely. This allows probing packets to be sent that represent customer traffic, possibly from multiple services (e.g., small Voice over IP packets, larger HTTP packets), and allows the embedding of useful monitoring data (e.g., accurate timestamps since both sender and receiver have the same clock and sequence numbers to ease the measurement).
o 監視パケットを送信するシステムも受信しています。監視パケットのペイロードは自由に選択できます。これにより、おそらく複数のサービス（例：小さなVoice over IPパケット、大きなHTTPパケット）からの顧客トラフィックを表すプローブパケットを送信でき、有用な監視データ（例：送信者と受信者の両方に正確なタイムスタンプがあるため）を埋め込むことができます。測定を容易にするために同じクロックとシーケンス番号）。
o Set up of a flexible MPLS monitoring system in terms of deployment: from one single centralized one to a set of distributed systems (e.g., on a per-region or service basis), and in terms of redundancy from 1+1 to N+1.
o 展開の観点からの柔軟なMPLSモニタリングシステムのセットアップ：単一の集中型システムから分散システムのセット（たとえば、リージョンごとまたはサービスベース）に、および1 + 1からN + 1の冗長性の観点から。
In addition to monitoring paths, problem localization is required. Topology awareness is an important feature of link-state IGPs deployed by operators of large networks. MPLS topology awareness combined with IGP topology awareness enables a simple and scalable data-plane-based monitoring mechanism. Faults can be localized:
パスの監視に加えて、問題のローカライズが必要です。トポロジ認識は、大規模ネットワークのオペレーターによって展開されるリンクステートIGPの重要な機能です。 MPLSトポロジ認識とIGPトポロジ認識を組み合わせると、シンプルでスケーラブルなデータプレーンベースの監視メカニズムが可能になります。障害はローカライズできます：
o by capturing the IGP topology and analyzing IGP messages indicating changes of it.
o IGPトポロジをキャプチャし、その変更を示すIGPメッセージを分析する。
o by correlation between different SR-based monitoring probes.
o 異なるSRベースのモニタリングプローブ間の相関によって。
o by setting up an MPLS traceroute packet for a path (or segment) to be tested and transporting it to a node to validate path connectivity from that node on.
o テストするパス（またはセグメント）のMPLS tracerouteパケットをセットアップし、ノードに転送して、そのノードからのパス接続を検証します。
MPLS OAM offers flexible traceroute (connectivity verification) features to detect and execute data paths of an MPLS domain. By utilizing the ECMP-related tool set offered, e.g., by RFC 8029 [RFC8029], an SR-based MPLS monitoring system can be enabled to:
MPLS OAMは、MPLSドメインのデータパスを検出して実行するための柔軟なtraceroute（接続検証）機能を提供します。 RFC 8029 [RFC8029]などによって提供されるECMP関連のツールセットを利用することで、SRベースのMPLSモニタリングシステムを有効にして、次のことが可能になります。
o detect how to route packets along different ECMP-routed paths.
o 異なるECMPルーティングパスに沿ってパケットをルーティングする方法を検出します。
o Construct ping packets that can be steered along a single path or ECMP towards a particular LER/LSR whose connectivity is to be checked.
o 接続がチェックされる特定のLER / LSRに向けて単一のパスまたはECMPに沿って誘導できるpingパケットを作成します。
o limit the MPLS label stack of such a ping packet, checking continuity of every single IGP segment to the maximum number of 3 labels. A smaller label stack may also be helpful, if any router interprets a limited number of packet header bytes to determine an ECMP along which to route a packet.
o このようなpingパケットのMPLSラベルスタックを制限し、すべてのIGPセグメントの連続性を最大3つのラベルにチェックします。いずれかのルーターが限られた数のパケットヘッダーバイトを解釈して、パケットをルーティングするECMPを決定する場合は、小さいラベルスタックも役立ちます。
Alternatively, any path may be executed by building suitable label stacks. This allows path execution without ECMP awareness.
あるいは、適切なラベルスタックを構築することにより、任意のパスを実行できます。これにより、ECMPを意識せずにパスを実行できます。
The MPLS PMS may be any server residing at a single interface of the
domain to be monitored. The PMS doesn't need to support the complete
MPLS routing or control plane. It needs to be capable of learning
and maintaining an accurate MPLS and IGP topology. MPLS ping and
traceroute packets need to be set up and sent with the correct
segment stack. The PMS must further be able to receive and decode
returning ping or traceroute packets. Packets from a variety of
protocols can be used to check continuity. These include Internet
Control Message Protocol (ICMP) [RFC0792] [RFC4443] [RFC4884]
[RFC4950], Bidirectional Forwarding Detection (BFD) [RFC5884],
Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880]
[RFC7881] (see Section 3.4 of [RFC7882]), and MPLS LSP ping
[RFC8029]. They can also have any other OAM format supported by the
PMS. As long as the packet used to check continuity returns to the
server while no IGP change is detected, the monitored path can be
considered as validated. If monitoring requires pushing a large
label stack, a software-based implementation is usually more flexible
than a hardware-based one. Hence, router label stack depth and label
composition limitations don't limit MPLS OAM choices.
RFC 8287 [RFC8287] discusses SR OAM applicability and MPLS traceroute enhancements adding functionality to the use cases described by this document.
RFC 8287 [RFC8287]では、SR OAMの適用性と、このドキュメントで説明されているユースケースに機能を追加するMPLS tracerouteの拡張について説明しています。
The document describes both use cases and a standalone monitoring framework. The monitoring system reuses existing IETF OAM protocols and leverage Segment Routing (Source Routing) to allow a single device to send, have exercised, and receive its own probing packets. As a consequence, there are no new interoperability considerations. A Standards Track RFC is not required; Informational status for this document is appropriate
このドキュメントでは、使用例とスタンドアロンの監視フレームワークの両方について説明します。監視システムは、既存のIETF OAMプロトコルを再利用し、セグメントルーティング（ソースルーティング）を利用して、単一のデバイスが独自のプローブパケットを送信、実行、および受信できるようにします。結果として、相互運用性に関する新しい考慮事項はありません。 Standards Track RFCは必須ではありません。このドキュメントの情報ステータスは適切です
Continuity Check
導通チェック
See Section 2.2.7 of RFC 7276 [RFC7276].
RFC 7276 [RFC7276]のセクション2.2.7を参照してください。
Connectivity Verification
接続性検証
See Section 2.2.7 of RFC 7276 [RFC7276].
RFC 7276 [RFC7276]のセクション2.2.7を参照してください。
MPLS topology
MPLSトポロジ
The MPLS topology of an MPLS domain is the complete set of MPLS-and IP-address information and all routing and data-plane information required to address and utilize every MPLS path within this domain from an MPLS PMS attached to this MPLS domain at an arbitrary access. This document assumes availability of the MPLS topology (which can be detected with available protocols and interfaces). None of the use cases will describe how to set it up.
MPLSドメインのMPLSトポロジは、MPLSおよびIPアドレス情報の完全なセットと、このMPLSドメインに接続されたMPLS PMSからこのドメイン内のすべてのMPLSパスを任意にアドレス指定して利用するために必要なすべてのルーティングおよびデータプレーン情報です。アクセス。このドキュメントでは、MPLSトポロジ（利用可能なプロトコルとインターフェイスで検出できる）の可用性を前提としています。使用方法のどれもそれを設定する方法を説明しません。
This document further adopts the terminology and framework described in [RFC8402].
このドキュメントは、[RFC8402]で説明されている用語とフレームワークをさらに採用しています。
ECMP Equal-Cost Multipath
ECMP等コストマルチパス
IGP Interior Gateway Protocol
IGP内部ゲートウェイプロトコル
LER Label Edge Router
LERラベルエッジルーター
LSP Label Switched Path
LSPラベルスイッチドパス
LSR Label Switching Router
LSRラベルスイッチングルータ
OAM Operations, Administration, and Maintenance
OAMの運用、管理、保守
PMS Path Monitoring System
PMSパス監視システム
RSVP-TE Resource Reservation Protocol - Traffic Engineering
RSVP-TEリソース予約プロトコル-トラフィックエンジニアリング
SID Segment Identifier
SIDセグメント識別子
SR Segment Routing
SRセグメントルーティング
SRGB Segment Routing Global Block
SRGBセグメントルーティンググローバルブロック
Any node at least listening to the IGP of an SR domain is MPLS topology aware (the node knows all related IP addresses, SR SIDs and MPLS labels). An MPLS PMS that is able to learn the IGP Link State Database (LSDB) (including the SIDs) is able to execute arbitrary chains of LSPs. To monitor an MPLS SR domain, a PMS needs to set up a topology database of the MPLS SR domain to be monitored. It may be used to send ping-type packets to only check continuity along such a path chain based only on the topology information. In addition, the PMS can be used to trace MPLS LSP and, thus, verify their connectivity and correspondence between control and data planes, respectively. The PMS can direct suitable MPLS traceroute packets to any node along a path segment.
SRドメインのIGPを少なくともリッスンしているノードは、MPLSトポロジーに対応しています（ノードはすべての関連IPアドレス、SR SID、およびMPLSラベルを知っています）。 IGPリンク状態データベース（LSDB）（SIDを含む）を学習できるMPLS PMSは、LSPの任意のチェーンを実行できます。 MPLS SRドメインを監視するには、PMSが監視対象のMPLS SRドメインのトポロジデータベースをセットアップする必要があります。これは、pingタイプのパケットを送信して、トポロジー情報のみに基づいてそのようなパスチェーンに沿った連続性のみをチェックするために使用できます。さらに、PMSを使用してMPLS LSPをトレースし、それらの接続性とコントロールプレーンとデータプレーン間の対応をそれぞれ確認できます。 PMSは、適切なMPLS tracerouteパケットをパスセグメントに沿った任意のノードに転送できます。
Let us describe how the PMS constructs a label stack to transport a packet to LER i, monitor its path to LER j, and then receive the packet back.
PMSがラベルスタックを構築してパケットをLER iに転送し、LER jへのパスを監視してからパケットを受信する方法について説明します。
The PMS may do so by sending packets carrying the following MPLS label stack information:
PMSは、次のMPLSラベルスタック情報を運ぶパケットを送信することによって、そうすることができます。
o Top Label: a path from PMS to LER i, which is expressed as Node-SID of LER i.
o トップラベル：PMSからLER iへのパス。LERiのNode-SIDとして表されます。
o Next Label: the path that needs to be monitored from LER i to LER j. If this path is a single physical interface (or a bundle of connected interfaces), it can be expressed by the related Adj-SID. If the shortest path from LER i to LER j is supposed to be monitored, the Node-SID (LER j) can be used. Another option is to insert a list of segments expressing the desired path (hop by hop as an extreme case). If LER i pushes a stack of labels based on an SR policy decision and this stack of LSPs is to be monitored, the PMS needs an interface to collect the information enabling it to address this SR-created path.
o 次のラベル：LER iからLER jへの監視が必要なパス。このパスが単一の物理インターフェイス（または接続されたインターフェイスのバンドル）の場合、関連するAdj-SIDで表すことができます。 LER iからLER jへの最短パスを監視する場合は、Node-SID（LER j）を使用できます。別のオプションは、目的のパスを表現するセグメントのリストを挿入することです（極端なケースとしてホップバイホップ）。 LER iがSRポリシーの決定に基づいてラベルのスタックをプッシュし、LSPのこのスタックが監視される場合、PMSは、SRが作成したこのパスに対処できるようにする情報を収集するためのインターフェイスを必要とします。
o Next Label or address: the path back to the PMS. Likely, no further segment/label is required here. Indeed, once the packet reaches LER j, the 'steering' part of the solution is done, and the probe just needs to return to the PMS. This is best achieved by popping the MPLS stack and revealing a probe packet with PMS as destination address (note that in this case, the source and destination addresses could be the same). If an IP address is applied, no SID/label has to be assigned to the PMS (if it is a host/server residing in an IP subnet outside the MPLS domain).
o 次のラベルまたはアドレス：PMSに戻るパス。おそらく、ここではそれ以上のセグメント/ラベルは必要ありません。実際、パケットがLER jに到達すると、ソリューションの「ステアリング」部分が実行され、プローブはPMSに戻るだけで済みます。これは、MPLSスタックをポップし、PMSを宛先アドレスとして持つプローブパケットを明らかにすることによって実現できます（この場合、送信元アドレスと宛先アドレスが同じになる可能性があることに注意してください）。 IPアドレスが適用される場合、SID /ラベルをPMSに割り当てる必要はありません（それがMPLSドメイン外のIPサブネットにあるホスト/サーバーの場合）。
The PMS should be physically connected to a router that is part of the SR domain. It must be able to send and receive MPLS packets via this interface. As mentioned above, the routing protocol support isn't required, and the PMS itself doesn't have to be involved in IGP or MPLS routing. A static route will do. The option to connect a PMS to an MPLS domain by a tunnel may be attractive to some operators. So far, MPLS separates networks securely by avoiding tunnel access to MPLS domains. Tunnel-based access of a PMS to an MPLS domain is out of scope of this document, as it implies additional security aspects.
PMSは、SRドメインの一部であるルーターに物理的に接続する必要があります。このインターフェイスを介してMPLSパケットを送受信できる必要があります。上記のように、ルーティングプロトコルのサポートは不要であり、PMS自体がIGPまたはMPLSルーティングに関与する必要はありません。スタティックルートで十分です。トンネルによってPMSをMPLSドメインに接続するオプションは、一部のオペレーターにとって魅力的です。これまでのところ、MPLSは、MPLSドメインへのトンネルアクセスを回避することにより、ネットワークを安全に分離します。 MPLSドメインへのPMSのトンネルベースのアクセスは、追加のセキュリティの側面を暗示するため、このドキュメントの範囲外です。
Figure 1 shows an example of this functional component as a system, which can be physical or virtual.
図1は、この機能コンポーネントのシステムとしての例を示しています。物理的または仮想的です。
+---+ +----+ +-----+
|PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2|-----|LER j|
+----+ +-----+
Figure 1: Example of a PMS-Based LSP Data-Plane Monitoring
図1：PMSベースのLSPデータプレーンモニタリングの例
For the sake of simplicity, let's assume that all the nodes are configured with the same SRGB [RFC8402].
簡単にするために、すべてのノードが同じSRGB [RFC8402]で構成されていると仮定します。
Let's assign the following Node-SIDs to the nodes of the figure: PMS = 10, LER i = 20, LER j = 30.
図のノードに次のNode-SIDを割り当てます。PMS= 10、LER i = 20、LER j = 30。
The aim is to set up a continuity check of the path between LER i and LER j. As has been said, the monitoring packets are to be sent and received by the PMS. Let's assume the design aim is to be able to work with the smallest possible SR label stack. In the given topology, a fairly simple option is to perform an MPLS path trace, as specified by RFC 8029 [RFC8029] (using the Downstream (Detailed) Mapping information resulting from a path trace). The starting point for the path trace is LER i and the PMS sends the MPLS path trace packet to LER i. The MPLS echo reply of LER i should be sent to the PMS. As a result, the IP destination address choices are detected, which are then used to target any one of the ECMP-routed paths between LER i and LER j by the MPLS ping packets to later check path continuity. The label stack of these ping packets doesn't need to consist of more than 3 labels. Finally, the PMS sets up and sends packets to monitor connectivity of the ECMP routed paths. The PMS does this by creating a measurement packet with the following label stack (top to bottom): 20 - 30 - 10. The ping packets reliably use the monitored path, if the IP-address information that has been detected by the MPLS traceroute is used as the IP destination address (note that this IP address isn't used or required for any IP routing).
目的は、LER iとLER jの間のパスの連続性チェックをセットアップすることです。すでに述べたように、監視パケットはPMSによって送受信されます。設計の目的が、可能な限り最小のSRラベルスタックで機能できるようにすることを想定しましょう。所定のトポロジでは、RFC 8029 [RFC8029]で指定されているように、MPLSパストレースを実行する（パストレースから生じるダウンストリーム（詳細）マッピング情報を使用する）というかなり単純なオプションがあります。パストレースの開始点はLER iで、PMSはMPLSパストレースパケットをLER iに送信します。 LER iのMPLSエコー応答をPMSに送信する必要があります。その結果、IP宛先アドレスの選択肢が検出されます。これは、MPLS pingパケットによってLER iとLER jの間のECMPルーティングされたパスのいずれか1つを対象として、後でパスの連続性をチェックするために使用されます。これらのpingパケットのラベルスタックは、3つ以上のラベルで構成する必要はありません。最後に、PMSはパケットをセットアップして送信し、ECMPルーティングパスの接続を監視します。 PMSは、次のラベルスタック（上から下）で測定パケットを作成することでこれを行います。20-30-10. MPLS tracerouteによって検出されたIPアドレス情報が次の場合、pingパケットは監視対象のパスを確実に使用しますIP宛先アドレスとして使用されます（このIPアドレスは、どのIPルーティングでも使用または必須ではないことに注意してください）。
LER m forwards the packet received from the PMS to LSR1. Assuming Penultimate Hop Popping is deployed, LSR1 pops the top label and forwards the packet to LER i. There the top label has a value 30 and LER i forwards it to LER j. This will be done transmitting the packet via LSR1 or LSR2. The LSR will again pop the top label. LER j will forward the packet now carrying the top label 10 to the PMS (and it will pass a LSR and LER m).
LER mは、PMSから受信したパケットをLSR1に転送します。最後から2番目のホップポッピングが展開されている場合、LSR1はトップラベルをポップし、パケットをLER iに転送します。そこで、トップラベルの値は30で、LER iはそれをLER jに転送します。これは、LSR1またはLSR2を介してパケットを送信することで行われます。 LSRは再びトップラベルをポップします。 LER jは、現在トップラベル10を持っているパケットをPMSに転送します（LSRとLER mを渡します）。
A few observations on the example given in Figure 1:
図1に示す例に関するいくつかの観察：
o The path from PMS to LER i must be available (i.e., a continuity check along the path to LER i must succeed). If desired, an MPLS traceroute may be used to exactly detect the data-plane path taken for this MPLS segment. It is usually sufficient to just apply any of the existing Shortest Path routed paths.
o PMSからLER iへのパスが利用可能である必要があります（つまり、LER iへのパスに沿った連続性チェックが成功する必要があります）。必要に応じて、MPLS tracerouteを使用して、このMPLSセグメントで使用されるデータプレーンパスを正確に検出できます。通常は、既存の最短パスルーティングパスを適用するだけで十分です。
o If ECMP is deployed, separate continuity checks monitoring all possible paths that a packet may use between LER i and LER j may be desired. This can be done by applying an MPLS traceroute between LER i and LER j. Another option is to use SR, but this will likely require additional label information within the label stack of the ping packet. Further, if multiple links are deployed between two nodes, SR methods to address each individual path require an Adj-SID to be assigned to each single interface. This method is based on control-plane information -- a connectivity verification based on MPLS traceroute seems to be a fairly good option to deal with ECMP and validation of correlation between control and data planes.
o ECMPが配備されている場合、パケットがLER iとLER jの間で使用する可能性のあるすべての可能なパスを監視する個別の連続性チェックが必要な場合があります。これは、LER iとLER jの間にMPLS tracerouteを適用することで実行できます。別のオプションはSRを使用することですが、これにはpingパケットのラベルスタック内に追加のラベル情報が必要になる可能性があります。さらに、2つのノード間に複数のリンクが配置されている場合、個々のパスをアドレス指定するSRメソッドでは、Adj-SIDを各単一のインターフェースに割り当てる必要があります。この方法はコントロールプレーン情報に基づいています。MPLStracerouteに基づく接続検証は、ECMPおよびコントロールプレーンとデータプレーン間の相関の検証を処理するためのかなり良いオプションのようです。
o The path LER j to PMS must be available (i.e., a continuity check only along the path from LER j to PMS must succeed). If desired, an MPLS traceroute may be used to exactly detect the data-plane path taken for this MPLS segment. It is usually sufficient to just apply any of the existing Shortest Path routed paths.
o PLERへのLER jのパスが利用可能である必要があります（つまり、LER jからPMSへのパスに沿った連続性チェックのみが成功する必要があります）。必要に応じて、MPLS tracerouteを使用して、このMPLSセグメントで使用されるデータプレーンパスを正確に検出できます。通常は、既存の最短パスルーティングパスを適用するだけで十分です。
Once the MPLS paths (Node-SIDs) and the required information to deal with ECMP have been detected, the path continuity between LER i and LER j can be monitored by the PMS. Path continuity monitoring by ping packets does not require the MPLS OAM functionality described in RFC 8029 [RFC8029]. All monitoring packets stay on the data plane; hence, path continuity monitoring does not require control-plane interaction in any LER or LSR of the domain. To ensure consistent interpretation of the results, the PMS should be aware of any changes in IGP or MPLS topology or ECMP routing. While this document describes path connectivity checking as a basic application, additional monitoring (like checking continuity of underlying physical infrastructure or performing delay measurements) may be desired. A change in ECMP routing that is not caused by an IGP or MPLS topology change may not be desirable for connectivity checks and delay measurements. Therefore, a PMS should also periodically verify connectivity of the SR paths that are monitored for continuity.
MPLSパス（Node-SID）とECMPを処理するために必要な情報が検出されると、LER iとLER jの間のパスの連続性をPMSで監視できます。 pingパケットによるパスの継続性の監視には、RFC 8029 [RFC8029]で説明されているMPLS OAM機能は必要ありません。すべてのモニタリングパケットはデータプレーンに留まります。したがって、パスの継続性の監視では、ドメインのLERまたはLSRでのコントロールプレーンの相互作用は必要ありません。結果の一貫した解釈を保証するために、PMSはIGPまたはMPLSトポロジーまたはECMPルーティングの変更を認識している必要があります。このドキュメントでは、基本的なアプリケーションとしてのパス接続チェックについて説明していますが、追加の監視（基礎となる物理インフラストラクチャの継続性のチェックや遅延測定の実行など）が必要になる場合があります。 IGPまたはMPLSトポロジの変更が原因ではないECMPルーティングの変更は、接続性チェックと遅延測定には望ましくない場合があります。したがって、PMSは、継続性が監視されているSRパスの接続を定期的に確認する必要もあります。
Determining a path to be executed prior to a measurement may also be done by setting up a label stack including all Node-SIDs along that path (if LSR1 has Node-SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is that it does not involve connectivity verification as specified in RFC 8029 [RFC8029] and, if there's only one physical connection between all nodes, the approach is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths of an MPLS domain. If correct forwarding along the desired paths has to be checked, or multiple physical connections exist between any two nodes, all Adj-SIDs along that path should be part of the label stack.
測定の前に実行されるパスの決定は、そのパスに沿ったすべてのノードSIDを含むラベルスタックをセットアップすることによって行うこともできます（例のLSR1にノードSID 40があり、それをLER iとLER jの間で渡す必要がある場合、ラベルスタックは20-40-30-10）です。この方法の利点は、RFC 8029 [RFC8029]で指定されている接続検証が含まれないことです。また、すべてのノード間に物理接続が1つしかない場合、アプローチはECMP機能から独立しています。この方法でも、MPLSドメインのすべてのパスのすべてのリンクの組み合わせを監視できます。目的のパスに沿った正しい転送を確認する必要がある場合、または任意の2つのノード間に複数の物理接続が存在する場合、そのパスに沿ったすべてのAdj-SIDはラベルスタックの一部である必要があります。
While a single PMS can detect the complete MPLS control- and data-plane topology, a reliable deployment requires two separated PMSs. Scalable permanent surveillance of a set of LSPs could require deployment of several PMSs. The PMS may be a router, but could also be a dedicated monitoring system. If measurement system reliability is an issue, more than a single PMS may be connected to the MPLS domain.
単一のPMSは完全なMPLSコントロールプレーンおよびデータプレーントポロジを検出できますが、信頼性の高い配置には2つの別個のPMSが必要です。 LSPのセットのスケーラブルな永続的な監視には、いくつかのPMSの展開が必要になる場合があります。 PMSはルーターの場合がありますが、専用の監視システムにすることもできます。測定システムの信頼性に問題がある場合は、複数のPMSがMPLSドメインに接続されている可能性があります。
Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with limited effort and a unique possibility to scale a flexible monitoring solution as required by the operator (the number of PMSs deployed is independent of the locations of the origin and destination of the monitored paths). The PMS can be enabled to send MPLS OAM packets with the label stacks and address information identical to those of the monitoring packets to any node of the MPLS domain. The routers of the monitored domain should support MPLS LSP ping RFC 8029 [RFC8029]. They may also incorporate the additional enhancements defined in RFC 8287 [RFC8287] to incorporate further MPLS traceroute features. ICMP-ping-based continuity checks don't require router-control-plane activity. Prior to monitoring a path, MPLS OAM may be used to detect ECMP-dependent forwarding of a packet. A PMS may be designed to learn the IP address information required to execute a particular ECMP-routed path and interfaces along that path. This allows for the monitoring of these paths with label stacks reduced to a limited number of Node- SIDs resulting from Shortest Path First (SPF) routing. The PMS does not require access to information about LSR/LER management or data planes to do so.
SRに基づくPMSによるMPLSドメインの監視は、限られた労力で完全なMPLSドメインを監視するオプションを提供し、オペレーターの要求に応じて柔軟な監視ソリューションを拡張する独自の可能性を提供します（展開されるPMSの数は、起点の場所とは無関係です）および監視対象パスの宛先）。 PMSを有効にして、監視パケットと同じラベルスタックとアドレス情報を持つMPLS OAMパケットをMPLSドメインの任意のノードに送信できます。監視対象ドメインのルーターは、MPLS LSP ping RFC 8029 [RFC8029]をサポートする必要があります。また、RFC 8287 [RFC8287]で定義されている追加の拡張機能を組み込んで、さらにMPLS traceroute機能を組み込むこともできます。 ICMP-pingベースの導通チェックでは、ルーターコントロールプレーンアクティビティは必要ありません。パスを監視する前に、MPLS OAMを使用して、パケットのECMP依存転送を検出できます。 PMSは、特定のECMPルーティングされたパスとそのパスに沿ったインターフェイスを実行するために必要なIPアドレス情報を学習するように設計できます。これにより、ラベルスタックを使用してこれらのパスを監視し、SPF（Shortest Path First）ルーティングの結果、ノードSIDの数を制限できます。 PMSは、LSR / LER管理またはデータプレーンに関する情報にアクセスする必要はありません。
+---+ _ +--+ +-------+
| | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| |
+---+ +--+ +-------+
Figure 2: SR-Based Probing of All the Links of a Remote Bundle
図2：リモートバンドルのすべてのリンクのSRベースのプローブ
In the figure, R1 addresses Link "x" Lx by the Adj-SID 99x, while R2 addresses Link Lx by the Adj-SID 66(x+1).
この図では、R1はリンク "x" LxをAdj-SID 99xでアドレス指定し、R2はリンクLxをAdj-SID 66（x + 1）でアドレス指定しています。
In the above figure, the PMS needs to assess the data-plane availability of all the links within a remote bundle connected to routers R1 and R2.
上の図では、PMSは、ルーターR1およびR2に接続されたリモートバンドル内のすべてのリンクのデータプレーンの可用性を評価する必要があります。
The monitoring system retrieves the SID/label information from the IGP LSDB and appends the following segment list/label stack: {72, 662, 992, 664} on its IP probe (whose source and destination addresses are the address of the PMS).
監視システムは、IGP LSDBからSID /ラベル情報を取得し、そのIPプローブにソースリストと宛先アドレスがPMSのアドレスであるセグメントリスト/ラベルスタック{72、662、992、664}を追加します。
The PMS sends the probe to its connected router. The MPLS/SR domain then forwards the probe to R2 (72 is the Node-SID of R2). R2 forwards the probe to R1 over link L1 (Adj-SID 662). R1 forwards the probe to R2 over link L2 (Adj-SID 992). R2 forwards the probe to R1 over link L3 (Adj-SID 664). R1 then forwards the IP probe to the PMS as per classic IP forwarding.
PMSは、接続されているルーターにプローブを送信します。次に、MPLS / SRドメインはプローブをR2に転送します（72はR2のノードSIDです）。 R2はリンクL1（Adj-SID 662）を介してプローブをR1に転送します。 R1はリンクL2（Adj-SID 992）を介してプローブをR2に転送します。 R2はリンクL3（Adj-SID 664）を介してプローブをR1に転送します。次に、R1は従来のIP転送と同様にIPプローブをPMSに転送します。
As was mentioned in Section 4.1, the PMS must be able to monitor the continuity of the path PMS to R2 (Node-SID 72) as well as the continuity from R1 to the PMS. If both are given and packets are lost, forwarding on one of the three interfaces connecting R1 to R2 must be disturbed.
セクション4.1で述べたように、PMSは、PMSからR2へのパス（Node-SID 72）の連続性と、R1からPMSへの連続性を監視できる必要があります。両方が指定され、パケットが失われた場合、R1からR2に接続している3つのインターフェースの1つでの転送を妨害する必要があります。
In the previous example, a unidirectional fault on the middle link in direction of R2 to R1 would be localized by sending the following two probes with respective segment lists:
前の例では、R2からR1の方向にある中間リンクの単一方向の障害は、次の2つのプローブをそれぞれのセグメントリストとともに送信することによってローカライズされます。
o 72, 662, 992, 664
o ７２、 ６６２、 ９９２、 ６６４
o 72, 663, 992, 664
o ７２、 ６６３、 ９９２、 ６６４
The first probe would succeed while the second would fail. Correlation of the measurements reveals that the only difference is using the Adj-SID 663 of the middle link from R2 to R1 in the unsuccessful measurement. Assuming the second probe has been routed correctly, the problem is that, for some (possibly unknown) reason, SR packets to be forwarded from R2 via the interface identified by Adj-SID 663 are lost.
最初のプローブは成功し、2番目のプローブは失敗します。測定値の相関から、唯一の違いは、失敗した測定でR2からR1への中間リンクのAdj-SID 663を使用していることです。 2番目のプローブが正しくルーティングされたと仮定すると、何らかの理由で（おそらく不明）、Adj-SID 663で識別されるインターフェースを介してR2から転送されるSRパケットが失われるという問題があります。
The example above only illustrates a method to localize a fault by correlated continuity checks. Any operational deployment requires well-designed engineering to allow for the desired unambiguous diagnosis on the monitored section of the SR network. 'Section' here could be a path, a single physical interface, the set of all links of a bundle, or an adjacency of two nodes (just to name a few).
上記の例は、相関性のある連続性チェックによって障害を特定する方法のみを示しています。運用展開では、SRネットワークの監視対象セクションで望ましい明確な診断を可能にするために、適切に設計されたエンジニアリングが必要です。ここでの「セクション」は、パス、単一の物理インターフェース、バンドルのすべてのリンクのセット、または2つのノードの隣接関係（ほんの数例を挙げると）です。
Sometimes, forwarding along a single path doesn't work, even though the control-plane information is healthy. Such a situation may occur after maintenance work within a domain. An operator may perform on-demand tests, but execution of automated PMS path trace checks may be set up as well (scope may be limited to a subset of important end-to-end paths crossing the router or network section after completion of the maintenance work there). Upon detection of a path that can't be used, the operator needs to be notified. A check ensuring that a re-routing event is differed from a path facing whose forwarding behavior doesn't correspond to the control-plane information is necessary (but out of scope of this document).
コントロールプレーン情報が正常であっても、単一のパスに沿った転送が機能しない場合があります。このような状況は、ドメイン内の保守作業後に発生する可能性があります。オペレーターはオンデマンドテストを実行できますが、自動PMSパストレースチェックの実行も設定できます（スコープは、メンテナンスの完了後にルーターまたはネットワークセクションを通過する重要なエンドツーエンドパスのサブセットに制限される場合がありますそこで働く）。使用できない経路を検出すると、オペレーターに通知する必要があります。再ルーティングイベントが、転送動作がコントロールプレーン情報に対応しないパスフェーシングと異なることを確認するチェックが必要です（ただし、このドキュメントの範囲外です）。
Adding an automated problem solution to the PMS features only makes sense if the root cause of the symptom appears often, can be assumed to be unambiguous by its symptoms, can be solved by a predetermined chain of commands, is not collaterally damaged by the automated PMS reaction. A closer analysis is out of scope of this document.
PMS機能に自動化された問題解決策を追加することは、症状の根本原因が頻繁に現れ、その症状によって明確であると想定でき、所定のコマンドチェーンによって解決でき、自動化されたPMSによって付随的に損傷されない場合にのみ意味があります反応。詳細な分析は、このドキュメントの範囲外です。
The PMS is expected to check control-plane liveliness after a path repair effort was executed. It doesn't matter whether the path repair was triggered manually or by an automated system.
PMSは、パス修復作業が実行された後、コントロールプレーンの活性をチェックすることが期待されています。パスの修復が手動でトリガーされたのか、自動システムによってトリガーされたのかは関係ありません。
6. Applying SR to Monitoring LSPs That Are Not SR Based (LDP and Possibly RSVP-TE)
6. SRベースではないLSPのモニタリングへのSRの適用（LDPおよび場合によってはRSVP-TE）
The MPLS PMS described by this document can be realized with technology that is not SR based. Making such a monitoring system that is not SR MPLS based aware of a domain's complete MPLS topology requires, e.g., management-plane access to the routers of the domain to be monitored or set up of a dedicated tLDP tunnel per router to set up an LDP adjacency. To avoid the use of stale MPLS label information, the IGP must be monitored and MPLS topology must be aligned with IGP topology in a timely manner. Enhancing IGPs to the exchange of MPLS-topology information as done by SR significantly simplifies and stabilizes such an MPLS PMS.
このドキュメントで説明するMPLS PMSは、SRベースではないテクノロジーで実現できます。ドメインの完全なMPLSトポロジを認識するSR MPLSベースではない監視システムを作成するには、たとえば、監視対象のドメインのルーターへの管理プレーンアクセス、またはLDPをセットアップするためのルーターごとの専用tLDPトンネルのセットアップが必要です。隣接。古いMPLSラベル情報の使用を回避するには、IGPを監視し、MPLSトポロジーをIGPトポロジーとタイミングよく合わせる必要があります。 SRによるMPLSトポロジー情報の交換に合わせてIGPを拡張すると、このようなMPLS PMSが大幅に簡素化および安定化されます。
An SR-based PMS connected to an MPLS domain consisting of LER and LSRs supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR paths to transmit packets to and from the start and endpoints of LSPs that are not SR based to be monitored. In the example given in Figure 1, the label stack top to bottom may be as follows, when sent by the PMS:
すべてのノードでSRとLDPまたはRSVP-TEを並行してサポートするLERとLSRで構成されるMPLSドメインに接続されたSRベースのPMSは、SRパスを使用して、SRベースではないLSPの始点と終点との間でパケットを送信できます。監視されます。図1に示されている例では、PMSから送信された場合、ラベルスタックの上から下は次のようになります。
o Top: SR-based Node-SID of LER i at LER m.
o 上：LER mでのLER iのSRベースのノードSID。
o Next: LDP or RSVP-TE label identifying the path or tunnel, respectively, from LER i to LER j (at LER i).
o 次：LER iからLER jへのパスまたはトンネルをそれぞれ識別するLDPまたはRSVP-TEラベル（LER iで）。
o Bottom: SR-based Node-SID identifying the path to the PMS at LER j.
o 下：LER jのPMSへのパスを識別するSRベースのノードSID。
While the mixed operation shown here still requires the PMS to be aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS topology by the IGP and use this information.
ここに示す混合操作では、PMSがLER LDP-MPLSトポロジを認識する必要がありますが、PMSはIGPによってSR MPLSトポロジを学習し、この情報を使用する場合があります。
An implementation report on a PMS operating in an LDP domain is given in [MPLS-PMS-REPORT]. In addition, this report compares delays measured with a single PMS to the results measured by systems that are conformant with IP Performance Metrics (IPPM) connected to the MPLS domain at three sites (see [RFC6808] for IPPM conformance). The delay measurements of the PMS and the IPPM Measurement Agents were compared based on a statistical test in [RFC6576]. The Anderson Darling k-sample test showed that the PMS round-trip delay measurements are equal to those captured by an IPPM-conformant IP measurement system for 64 Byte measurement packets with 95% confidence.
LDPドメインで動作するPMSの実装レポートは、[MPLS-PMS-REPORT]で提供されます。さらに、このレポートは、単一のPMSで測定された遅延を、3つのサイトでMPLSドメインに接続されたIPパフォーマンスメトリック（IPPM）に準拠したシステムで測定された結果と比較します（IPPM準拠については[RFC6808]を参照）。 PMSとIPPM測定エージェントの遅延測定は、[RFC6576]の統計テストに基づいて比較されました。アンダーソンダーリングkサンプルテストでは、PMSラウンドトリップ遅延測定値が、95％の信頼度で64バイト測定パケットのIPPM準拠IP測定システムによってキャプチャされたものと等しいことが示されました。
The authors are not aware of similar deployment for RSVP-TE. Identification of tunnel entry- and transit-nodes may add complexity. They are not within scope of this document.
著者は、RSVP-TEの同様の展開については認識していません。トンネルエントリノードとトランジットノードの識別により、複雑さが増す場合があります。それらはこのドキュメントの範囲外です。
MPLS SR topology awareness should allow the PMS to monitor liveliness of SIDs related to interfaces within the SR and IGP domain, respectively. Tracing a path where an SR-capable node assigns an Adj-SID for a node that is not SR capable may fail. This and other backward compatibility with non-SR devices are discussed by RFC 8287 [RFC8287].
MPLS SRトポロジ認識により、PMSはSRおよびIGPドメイン内のインターフェースに関連するSIDの活性をそれぞれ監視できます。 SR対応のノードがSR対応ではないノードにAdj-SIDを割り当てるパスのトレースは失敗する場合があります。これと非SRデバイスとの下位互換性は、RFC 8287 [RFC8287]で説明されています。
To match control-plane information with data-plane information for all relevant types of Segment IDs, RFC 8287 [RFC8287] enhances MPLS OAM functions defined by RFC 8029 [RFC8029].
RFC 8287 [RFC8287]は、関連するすべてのタイプのセグメントIDのコントロールプレーン情報をデータプレーン情報と照合するために、RFC 8029 [RFC8029]で定義されたMPLS OAM機能を拡張します。
While the PMS-based use cases explained in Section 5 are sufficient to provide continuity checks between LER i and LER j, they may not help perform connectivity verification.
セクション5で説明したPMSベースの使用例は、LER iとLER j間の連続性チェックを提供するには十分ですが、接続検証の実行に役立つとは限りません。
+---+
|PMS|
+---+
|
|
+----+ +----+ +-----+
|LSRa|-----|LSR1|-----|LER i|
+----+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2| |LER j|
+----+ +-----+
Figure 3: Connectivity Verification with a PMS
図3：PMSによる接続検証
Let's assign the following Node-SIDs to the nodes of the figure: PMS = 10, LER i = 20, LER j = 30, LER m = 40. The PMS is intended to validate the path between LER m and LER j. In order to validate this path, the PMS will send the probe packet with a label stack of (top to bottom): {40} {30} {10}. Imagine any of the below forwarding entry misprogrammed situation:
図のノードに次のNode-SIDを割り当てます。PMS= 10、LER i = 20、LER j = 30、LER m =40。PMSは、LER mとLER jの間のパスを検証することを目的としています。このパスを検証するために、PMSは（上から下）のラベルスタック{40} {30} {10}を含むプローブパケットを送信します。以下の転送エントリの誤ってプログラムされた状況を想像してください。
o LSRa receiving any packet with top label 40 will POP and forwards to LSR1 instead of LER m.
o LSRaがトップラベル40のパケットを受信すると、POPが実行され、LER mではなくLSR1に転送されます。
o LSR1 receiving any packet with top label 30 will pop and forward to LER i instead of LER j.
o トップラベル30のパケットを受信するLSR1は、ポップして、LER jではなくLER iに転送します。
In either of the above situations, the probe packet will be delivered back to the PMS leading to a falsified path liveliness indication by the PMS.
上記のいずれかの状況では、プローブパケットがPMSに配信され、PMSによって改ざんされたパスの活性状態が示されます。
Connectivity Verification functions help us to verify if the probe is taking the expected path. For example, the PMS can intermittently send the probe packet with a label stack of (top to bottom): {40;ttl=255} {30;ttl=1} {10;ttl=255}. The probe packet may carry information about LER m, which could be carried in the Target FEC Stack in case of an MPLS Echo Request or Discriminator in the case of Seamless BFD. When LER m receives the packet, it will punt due to Time-To-Live (TTL) expiry and send a positive response. In the above-mentioned misprogramming situation, LSRa will forward to LSR1, which will send a negative response to the PMS as the information in probe does not match the local node. The PMS can do the same for bottom label as well. This will help perform connectivity verification and ensure that the path between LER m and LER j is working as expected.
接続性検証機能は、プローブが予想通りの経路をたどっているかどうかを検証するのに役立ちます。たとえば、PMSは（上から下）のラベルスタック{40; ttl = 255} {30; ttl = 1} {10; ttl = 255}のプローブパケットを断続的に送信できます。プローブパケットはLER mに関する情報を運ぶことがあります。これは、MPLSエコー要求の場合はターゲットFECスタックで、シームレスBFDの場合は弁別器で運ぶことができます。 LER mがパケットを受信すると、存続可能時間（TTL）の期限切れのためパントし、肯定応答を送信します。上記の誤ったプログラミング状況では、LSRaはLSR1に転送します。LSR1は、プローブの情報がローカルノードと一致しないため、PMSに否定応答を送信します。 PMSは、下部ラベルにも同じことを行うことができます。これは、接続検証を実行し、LER mとLER jの間のパスが期待どおりに機能していることを確認するのに役立ちます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The PMS builds packets with the intent of performing OAM tasks. It uses address information based on topology information rather than a protocol.
PMSは、OAMタスクを実行する目的でパケットを作成します。プロトコルではなく、トポロジー情報に基づいたアドレス情報を使用します。
The PMS allows the insertion of traffic into non-SR domains. This may be required in the case of an LDP domain attached to the SR domain, but it can be used to maliciously insert traffic in the case of external IP domains and MPLS-based VPNs.
PMSでは、SR以外のドメインにトラフィックを挿入できます。これは、SRドメインに接続されたLDPドメインの場合に必要になることがありますが、外部IPドメインおよびMPLSベースのVPNの場合に悪意を持ってトラフィックを挿入するために使用できます。
To prevent a PMS from inserting traffic into an MPLS VPN domain, one or more sets of label ranges may be reserved for service labels within an SR domain. The PMS should be configured to reject usage of these service label values. In the same way, misuse of IP destination addresses is blocked if only IP destination address values conforming to RFC 8029 [RFC8029] are settable by the PMS.
PMSがMPLS VPNドメインにトラフィックを挿入しないようにするために、SRドメイン内のサービスラベル用に1つ以上のラベル範囲のセットを予約できます。これらのサービスラベル値の使用を拒否するようにPMSを設定する必要があります。同様に、RFC 8029 [RFC8029]に準拠するIP宛先アドレス値のみがPMSによって設定可能である場合、IP宛先アドレスの誤用はブロックされます。
To limit potential misuse, access to a PMS needs to be authorized and should be logged. OAM supported by a PMS requires skilled personnel; hence, only experts requiring PMS access should be allowed to access such a system. It is recommended to directly attach a PMS to an SR domain. Connecting a PMS to an SR domain by a tunnel is technically possible, but adds further security issues. A tunnel-based access of a PMS to an SR domain is not recommended.
誤用の可能性を制限するには、PMSへのアクセスを承認し、ログに記録する必要があります。 PMSがサポートするOAMには熟練したスタッフが必要です。したがって、PMSアクセスを必要とする専門家だけがそのようなシステムへのアクセスを許可されるべきです。 PMSをSRドメインに直接接続することをお勧めします。トンネルでPMSをSRドメインに接続することは技術的には可能ですが、セキュリティの問題がさらに追加されます。 PMSからSRドメインへのトンネルベースのアクセスはお勧めしません。
Use of stale MPLS or IGP routing information could cause a PMS-monitoring packet to leave the domain where it originated. PMS-monitoring packets should not be sent using stale MPLS- or IGP-routing information. To carry out a desired measurement properly, the PMS must be aware of and respect the actual route changes, convergence events, as well as the assignment of Segment IDs relevant for measurements. At a minimum, the PMS must be able to listen to IGP topology changes or pull routing and segment information from routers signaling topology changes.
古いMPLSまたはIGPルーティング情報を使用すると、PMS監視パケットが元のドメインを離れる可能性があります。 PMS監視パケットは、古いMPLSまたはIGPルーティング情報を使用して送信しないでください。目的の測定を適切に実行するには、PMSは実際のルート変更、収束イベント、および測定に関連するセグメントIDの割り当てを認識し、尊重する必要があります。少なくとも、PMSはIGPトポロジの変更をリッスンできるか、トポロジの変更をシグナリングするルーターからルーティングおよびセグメント情報をプルできる必要があります。
Traffic insertion by a PMS may be unintended, especially if the IGP or MPLS topology stored locally is in stale state. As soon as the PMS has an indication that its IGP or MPLS topology are stale, it should stop operations involving network sections whose topology may not be accurate. However, note that it is the task of an OAM system to discover and locate network sections where forwarding behavior is not matching control-plane state. As soon as a PMS or an operator of a PMS has the impression that the PMS topology information is stale, measures need to be taken to refresh the topology information. These measures should be part of the PMS design. Matching forwarding and control-plane state by periodically automated execution of the mechanisms described in RFC 8029 [RFC8029] may be such a feature. Whenever network maintenance tasks are performed by operators, the PMS topology discovery should be started asynchronously after network maintenance has been finished.
特にローカルに保存されているIGPまたはMPLSトポロジが古い状態の場合、PMSによるトラフィック挿入は意図されていない可能性があります。 PMSは、IGPまたはMPLSトポロジーが古くなっていることを示すとすぐに、トポロジーが正確でない可能性があるネットワークセクションを含む操作を停止する必要があります。ただし、転送動作がコントロールプレーンの状態と一致しないネットワークセクションを検出して特定するのはOAMシステムのタスクであることに注意してください。 PMSまたはPMSのオペレーターがPMSトポロジー情報が古くなっていると感じたらすぐに、トポロジー情報をリフレッシュするための対策を講じる必要があります。これらの対策は、PMS設計の一部である必要があります。 RFC 8029 [RFC8029]で説明されているメカニズムの定期的に自動化された実行によって、転送とコントロールプレーンの状態を一致させることは、このような機能である可能性があります。オペレーターがネットワーク保守タスクを実行する場合は常に、ネットワーク保守が完了した後、PMSトポロジー検出を非同期で開始する必要があります。
A PMS that is losing network connectivity or crashing must remove all IGP- and MPLS-topology information prior to restarting operation.
ネットワーク接続が失われている、またはクラッシュしているPMSは、操作を再開する前にすべてのIGPおよびMPLSトポロジ情報を削除する必要があります。
A PMS may operate routine measurements on a large scale. Care must be taken to avoid unintended traffic insertion after topology changes that result in, e.g., changes of label assignments to routes or interfaces within a domain. If the labels concerned are part of the label stack composed by the PMS for any measurement packet and their state is stale, the measurement initially needs to be stopped. Setup and operation of routine measurements may be automated. Secure automated PMS operation requires a working automated detection and recognition of stale routing state.
PMSは、日常的な測定を大規模に運用する場合があります。ドメイン内のルートまたはインターフェースへのラベル割り当ての変更など、トポロジーの変更後に意図しないトラフィックが挿入されないように注意する必要があります。関係するラベルが、PMSによって測定パケット用に構成されたラベルスタックの一部であり、その状態が古い場合、最初に測定を停止する必要があります。ルーチン測定のセットアップと操作は自動化できます。安全な自動PMS操作には、古いルーティング状態の自動検出と認識が機能している必要があります。
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.
[RFC7276]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E。、およびY.ウェインガルテン、「運用、管理、および保守（OAM）ツールの概要」、RFC 7276、DOI 10.17487 / RFC7276、2014年6月、 <https://www.rfc-editor.org/info/rfc7276>。
[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。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[MPLS-PMS-REPORT] Leipnitz, R., Ed. and R. Geib, "A scalable and topology aware MPLS data plane monitoring system", Work in Progress, draft-leipnitz-spring-pms-implementation-report-00, June 2016.
[MPLS-PMS-REPORT]ライプニッツ、R。、エド。およびR.ガイブ、「スケーラブルでトポロジー対応のMPLSデータプレーンモニタリングシステム」、Work in Progress、draft-leipnitz-spring-pms-implementation-report-00、2016年6月。
[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>。
[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]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン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>。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, DOI 10.17487/RFC4950, August 2007, <https://www.rfc-editor.org/info/rfc4950>.
[RFC4950] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「マルチプロトコルラベルスイッチング用のICMP拡張機能」、RFC 4950、DOI 10.17487 / RFC4950、2007年8月、<https：// www。 rfc-editor.org/info/rfc4950>。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、DOI 10.17487 / RFC5884、2010年6月、<https://www.rfc-editor.org/info/rfc5884>。
[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <https://www.rfc-editor.org/info/rfc6576>.
[RFC6576] Geib、R.、Ed。、Morton、A.、Fardid、R。、およびA. Steinmitz、「IP Performance Metrics（IPPM）Standard Advancement Testing」、BCP 176、RFC 6576、DOI 10.17487 / RFC6576、March 2012、<https://www.rfc-editor.org/info/rfc6576>。
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track", RFC 6808, DOI 10.17487/RFC6808, December 2012, <https://www.rfc-editor.org/info/rfc6808>.
[RFC6808] Ciavattone、L.、Geib、R.、Morton、A。、およびM. Wieser、「Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track」、RFC 6808、DOI 10.17487 / RFC6808、2012年12月、 <https://www.rfc-editor.org/info/rfc6808>。
[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、「シームレス双方向転送検出（S-BFD）」、RFC 7880、DOI 10.17487 / RFC7880、2016年7月、<https://www.rfc-editor.org/info/rfc7880>。
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, <https://www.rfc-editor.org/info/rfc7881>.
[RFC7881] Pignataro、C.、Ward、D。、およびN. Akiya、「IPv4、IPv6、およびMPLSのシームレスな双方向転送検出（S-BFD）」、RFC 7881、DOI 10.17487 / RFC7881、2016年7月、<https ：//www.rfc-editor.org/info/rfc7881>。
[RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, "Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016, <https://www.rfc-editor.org/info/rfc7882>.
[RFC7882] Aldrin、S.、Pignataro、C.、Mirsky、G。、およびN. Kumar、「シームレスな双方向転送検出（S-BFD）の使用例」、RFC 7882、DOI 10.17487 / RFC7882、2016年7月、<https ：//www.rfc-editor.org/info/rfc7882>。
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、and M. Chen、 "Detecting Multiprotocol Label Switched（MPLS）Data-Plane Failures、" RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https://www.rfc-editor.org/info/rfc8029>。
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.
[RFC8287] Kumar、N.、Ed。、Pignataro、C.、Ed。、Swallow、G.、Akiya、N.、Kini、S.、and M. Chen、 "Label Switched Path（LSP）Ping / Traceroute for Segment Routing（SR）IGP-Prefix and IGP-Adjacency Segment Identifiers（SIDs with MPLS Data Planes）」、RFC 8287、DOI 10.17487 / RFC8287、2017年12月、<https://www.rfc-editor.org/info/rfc8287 >。
Acknowledgements
謝辞
The authors would like to thank Nobo Akiya for his contribution. Raik Leipnitz kindly provided an editorial review. The authors would also like to thank Faisal Iqbal for an insightful review and a useful set of comments and suggestions. Finally, Bruno Decraene's Document Shepherd review led to a clarified document.
著者は彼の貢献のためにNobo Akiyaに感謝したいと思います。 Raik Leipnitzが編集レビューを提供してくれました。著者はまた、洞察に満ちたレビューと有用なコメントと提案のセットを提供してくれたファイサルイクバルに感謝します。最後に、ブルーノデクレイネのドキュメントシェパードレビューにより、ドキュメントが明確になりました。
Authors' Addresses
著者のアドレス
Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib（編集者）Deutsche Telekom Heinrich Hertz Str。 3-7ダルムシュタット64295ドイツ
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
Clarence Filsfils Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils Cisco Systems、Inc.ブリュッセルベルギー
Email: cfilsfil@cisco.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America
Carlos Pignataro（編集者）Cisco Systems、Inc. 7200 Kit Creek Road Research Triangle Park、NC 27709-4987アメリカ合衆国
Email: cpignata@cisco.com
Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America
Nagendra Kumar Cisco Systems、Inc. 7200 Kit Creek Road Research Triangle Park、NC 27709-4987アメリカ合衆国
Email: naikumar@cisco.com