[要約] RFC 6426は、MPLSネットワークでのオンデマンド接続の検証と経路トレースに関する標準仕様です。その目的は、MPLSネットワークのトラブルシューティングとパフォーマンスの向上を支援することです。
Internet Engineering Task Force (IETF) E. Gray
Request for Comments: 6426 Ericsson
Updates: 4379 N. Bahadur
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 S. Boutros
Cisco Systems, Inc.
R. Aggarwal
November 2011
MPLS On-Demand Connectivity Verification and Route Tracing
MPLSオンデマンド接続検証とルートトレース
Abstract
概要
Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry.
ラベルスイッチ付きパスPing（LSP Ping）は、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）の既存および広く展開された操作、管理、およびメンテナンス（OAM）メカニズムです。このドキュメントでは、LSP Pingの拡張機能について説明して、LSP PingをMPLS輸送プロファイル（MPLS-TP）LSPおよび擬似ワイヤのオンデマンド接続検証に使用できます。このドキュメントでは、関連するOAMパケットの処理に使用する手順も明確にします。さらに、LSP Pingを使用してMPLS-TPネットワークで接続検証とルートトレース機能を実行する手順について説明します。最後に、このドキュメントは、新しいアドレスタイプを追加し、IANAレジストリを作成することにより、RFC 4379を更新します。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6426.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6426で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. On-Demand CV for MPLS-TP LSPs Using IP Encapsulation . . . 4
1.3. On-Demand CV for MPLS-TP LSPs Using Non-IP
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 4
2. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 5
2.1. New Address Type for Downstream Mapping TLV . . . . . . . 5
2.1.1. DSMAP/DDMAP Non-IP Address Information . . . . . . . . 5
2.2. Source/Destination Identifier TLV . . . . . . . . . . . . 7
2.2.1. Source/Destination Identifier TLV Format . . . . . . . 7
2.2.2. Source Identifier TLV . . . . . . . . . . . . . . . . 7
2.2.3. Destination Identifier TLV . . . . . . . . . . . . . . 8
2.3. Identifying Statically Provisioned LSPs and PWs . . . . . 8
2.3.1. Static LSP Sub-TLV . . . . . . . . . . . . . . . . . . 9
2.3.2. Static Pseudowire Sub-TLV . . . . . . . . . . . . . . 10
3. Performing On-Demand CV over MPLS-TP LSPs . . . . . . . . . . 10
3.1. LSP Ping with IP Encapsulation . . . . . . . . . . . . . . 11
3.2. On-Demand CV with IP Encapsulation, over ACH . . . . . . . 11
3.3. Non-IP-Based On-Demand CV, Using ACH . . . . . . . . . . . 12
3.4. Reverse-Path Connectivity Verification . . . . . . . . . . 13
3.4.1. Requesting Reverse-Path Connectivity Verification . . 13
3.4.2. Responder Procedures . . . . . . . . . . . . . . . . . 13
3.4.3. Requester Procedures . . . . . . . . . . . . . . . . . 14
3.5. P2MP Considerations . . . . . . . . . . . . . . . . . . . 14
3.6. Management Considerations for Operation with Static
MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7. Generic Associated Channel Label (GAL) Processing . . . . 14
4. Performing On-Demand Route Tracing over MPLS-TP LSPs . . . . . 15
4.1. On-Demand LSP Route Tracing with IP Encapsulation . . . . 15
4.2. Non-IP-Based On-Demand LSP Route Tracing, Using ACH . . . 15
4.2.1. Requester Procedure for Sending Echo Request
Packets . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Requester Procedure for Receiving Echo Response
Packets . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Responder Procedure . . . . . . . . . . . . . . . . . 16
4.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 16
4.4. ECMP Considerations . . . . . . . . . . . . . . . . . . . 16
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. New Source and Destination Identifier TLVs . . . . . . . . 17
7.2. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 17
7.3. New Reverse-Path Target FEC Stack TLV . . . . . . . . . . 18
7.4. New Pseudowire Associated Channel Type . . . . . . . . . . 18
7.5. New Downstream Mapping Address Type Registry . . . . . . . 18
8. Contributing Authors and Acknowledgements . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Label Switched Path Ping (LSP ping) [RFC4379] is an Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand monitoring of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. It also clarifies the procedures to be used for processing the related OAM packets. This document describes how LSP ping can be used for on-demand connectivity verification (Section 3) and route tracing (Section 4) functions required in [RFC5860] and specified in [RFC6371].
ラベルスイッチパスPing（LSP Ping）[RFC4379]は、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）の動作、管理、およびメンテナンス（OAM）メカニズムです。このドキュメントでは、LSP Pingの拡張機能について説明して、LSP PingをMPLS輸送プロファイル（MPLS-TP）LSPおよび擬似動物のオンデマンドモニタリングに使用できます。また、関連するOAMパケットの処理に使用する手順を明確にします。このドキュメントでは、[RFC5860]で必要なオンデマンド接続検証（セクション3）およびルートトレース（セクション4）関数に[RFC5860]で必要な関数にLSP Pingを使用する方法について説明します。
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 [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。
There is considerable opportunity for confusion in use of the terms "on-demand connectivity verification" (CV), "on-demand route tracing" and "LSP ping." In this document, we try to use the terms consistently as follows:
「オンデマンド接続検証」（CV）、「オンデマンドルートトレース」、「LSP Ping」という用語の使用には、混乱するかなりの機会があります。このドキュメントでは、次のように一貫して用語を使用しようとします。
o LSP ping: refers to the mechanism - particularly as defined and used in referenced material;
o LSP ping：メカニズムを指します - 特に参照された材料で定義され、使用されています。
o On-demand CV: refers to on-demand connectivity verification and -- where both apply equally -- on-demand route tracing, as implemented using the LSP ping mechanism extended for support of MPLS-TP;
o オンデマンドCV：MPLS-TPのサポートのために拡張されたLSP Pingメカニズムを使用して実装されているように、オンデマンド接続検証と、両方とも均等に適用される場合、オンデマンドルートトレースを指します。
o On-demand route tracing: used in those cases where the LSP ping mechanism (as extended) is used exclusively for route tracing.
o オンデマンドルートトレース：LSP Pingメカニズム（拡張中）がルートトレース専用に使用される場合に使用されます。
From the perspective of on-demand CV and route tracing, we use the concepts of "Requester" and "Responder" as follows:
オンデマンドCVとルートトレースの観点から、次のように「要求者」と「応答者」の概念を使用します。
o Requester: Originator of an OAM Request message,
o リクエスター：OAMリクエストメッセージのオリジネーター、
o Responder: Entity responding to an OAM Request message.
o レスポンダー：OAM要求メッセージに応答するエンティティ。
Since, in this document, all messages are assumed to be carried in an LSP, all Request messages would be injected at the ingress to an LSP. A Responder might or might not be at the egress of this same LSP, given that it could receive Request messages as a result of time-to-live (TTL) expiry. If a Reply is to be delivered via a reverse-path LSP, the message would again be inserted at the ingress of that LSP.
このドキュメントでは、すべてのメッセージがLSPで運ばれると想定されるため、すべてのリクエストメッセージは入り込みでLSPに注入されます。レスポンダーは、この同じLSPの出口にいる場合とそうでない場合があります。返信がリバースパスLSPを介して配信される場合、メッセージは再びそのLSPの入り口に挿入されます。
LSP ping requires IP addressing on responding Label Switching Routers (LSRs) for performing OAM on MPLS-signaled LSPs and pseudowires. In particular, in these cases, LSP ping packets generated by a Requester are encapsulated in an IP/UDP header with the destination address from the 127/8 range and then encapsulated in the MPLS label stack ([RFC4379] , [RFC5884]). A Responder uses the presence of the 127/8 destination address to identify OAM packets and relies further on the UDP port number to determine whether the packet is an LSP ping packet. It is to be noted that this determination does not require IP forwarding capabilities. It requires the presence of an IP host stack, which enables responding LSRs to process packets with a destination address from the 127/8 range. [RFC1122] allocates the 127/8 range as "Internal host loopback address" and [RFC1812] states that "a router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127".
LSP Pingでは、MPLSシグナル付きLSPおよび擬似動物でOAMを実行するために、応答ラベルスイッチングルーター（LSR）のIPアドレス指定が必要です。特に、これらの場合、要求者によって生成されたLSP pingパケットは、127/8範囲の宛先アドレスを持つIP/UDPヘッダーにカプセル化され、MPLSラベルスタック（[RFC4379]、[RFC5884]）にカプセル化されます。レスポンダーは、127/8の宛先アドレスの存在を使用してOAMパケットを識別し、UDPポート番号にさらに依存して、パケットがLSP pingパケットであるかどうかを判断します。この決定には、IP転送機能が必要ないことに注意してください。 IPホストスタックの存在が必要です。これにより、応答するLSRSが127/8の範囲から宛先アドレスでパケットを処理できるようにします。 [RFC1122]は、127/8の範囲を「内部ホストループバックアドレス」として割り当て、[RFC1812]は、「ループバックインターフェイスを除き、ネットワーク127に宛先アドレスを持つパケットを除き、ルーターは転送しないでください」と述べています。
In certain MPLS-TP deployment scenarios, IP addressing might not be available or use some form of non-IP encapsulation might be preferred for on-demand CV, route tracing, and BFD packets. In such scenarios, on-demand CV and/or route tracing SHOULD be run without IP addressing, using the Associated Channel (ACH) channel type specified in Section 3.
特定のMPLS-TP展開シナリオでは、IPアドレス指定が利用できないか、オンデマンドCV、ルートトレース、BFDパケットには何らかの形の非IPカプセル化が優先される場合があります。このようなシナリオでは、セクション3で指定された関連チャネル（ACH）チャネルタイプを使用して、IPアドレスを使用してオンデマンドCVおよび/またはルートトレースを実行する必要があります。
Section 3.3 and Section 4.2 describe the theory of operation for performing on-demand CV over MPLS-TP LSPs with any non-IP encapsulation.
セクション3.3およびセクション4.2は、非IPカプセル化を使用してMPLS-TP LSPを介してオンデマンドCVを実行するための動作理論について説明します。
[RFC4379] defines the Downstream Mapping (DSMAP) TLV. [RFC6424] further defines the Downstream Detailed Mapping (DDMAP) TLV. This document defines the following new address type, which MAY be used in any DSMAP or DDMAP TLV included in an on-demand CV message:
[RFC4379]は、下流マッピング（DSMAP）TLVを定義します。[RFC6424]は、下流の詳細マッピング（DDMAP）TLVをさらに定義します。このドキュメントでは、次の新しいアドレスタイプを定義します。これは、オンデマンドCVメッセージに含まれるDSMAPまたはDDMAP TLVで使用できます。
Type # Address Type K Octets
------ -------------- --------
5 Non IP 12
Figure 1: New Downstream Mapping Address Type
図1：新しいダウンストリームマッピングアドレスタイプ
The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of "IF_Num" in [RFC6370]) for both ingress and egress interfaces, as well as Multipath Information, is included in the format and MAY be present.
新しいアドレスタイプは、DSMAPまたはDDMAP TLVにアドレスが存在しないことを示しています。ただし、IF_NUM情報（[RFC6370]の「if_num」の定義を参照）、および侵入インターフェイスと出口インターフェイスの両方、およびマルチパス情報の両方が形式に含まれており、存在する場合があります。
IF_Num values of zero indicate that no IF_Num applies in the field in which this value appears.
ゼロのif_num値は、この値が表示されるフィールドにif_numが適用されないことを示します。
The Multipath Type SHOULD be set to zero (no multipath) when using this address type.
このアドレスタイプを使用する場合、マルチパスタイプはゼロ（マルチパスなし）に設定する必要があります。
When this address type is used, on receipt of an LSP ping echo request, interface verification MUST be bypassed. Thus, the receiving node SHOULD only perform MPLS label control-plane/ data-plane consistency checks. Note that these consistency checks include checking the included identifier information.
このアドレスタイプを使用する場合、LSP pingエコー要求を受け取ったときに、インターフェイスの検証をバイパスする必要があります。したがって、受信ノードは、MPLSラベル制御プレーン/データプレーンの一貫性チェックのみを実行する必要があります。これらの一貫性チェックには、含まれる識別子情報のチェックが含まれることに注意してください。
The new address type is also applicable to the Detailed Downstream Mapping (DDMAP) TLV defined in [RFC6424].
新しいアドレスタイプは、[RFC6424]で定義されている詳細な下流マッピング（DDMAP）TLVにも適用できます。
If the DSMAP (or DDMAP) TLV is included when sending on-demand CV packets using ACH, without IP encapsulation, the following information MUST be included in any DSMAP or DDMAP TLV that is included in the packet. This information forms the address portion of the DSMAP TLV (as defined in [RFC4379]) or DDMAP TLV (as defined in [RFC6424] using one of the address information fields defined in
IPカプセル化なしにACHを使用してオンデマンドCVパケットを送信するときにDSMAP（またはDDMAP）TLVが含まれている場合、パケットに含まれるDSMAPまたはDDMAP TLVに次の情報を含める必要があります。この情報は、DSMAP TLV（[RFC4379]で定義されている）またはDDMAP TLV（[RFC6424で定義されている）のアドレス部分を形成します。
[RFC4379] and extended to include non-IP identifier types in this document).
[RFC4379]およびこのドキュメントに非IP識別子タイプを含めるように拡張されました）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IF_Num (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress IF_Num (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: New DSMAP/DDMAP Address Format
図2：新しいDSMAP/DDMAPアドレス形式
Address Type will be 5 (as shown in Section 2.1 above).
アドレスタイプは5になります（上記のセクション2.1に示すように）。
Ingress IF_Num identifies the ingress interface on the target node. A value of zero indicates that the interface is not part of the identifier.
Ingress if_numは、ターゲットノード上のイングレスインターフェイスを識別します。ゼロの値は、インターフェイスが識別子の一部ではないことを示します。
Egress IF_Num identifies the egress interface on the target node. A value of zero indicates that the interface is not part of the identifier.
出力if_numは、ターゲットノードの出力インターフェイスを識別します。ゼロの値は、インターフェイスが識別子の一部ではないことを示します。
The Multipath Type SHOULD be set to zero (no multipath) when using this address type.
このアドレスタイプを使用する場合、マルチパスタイプはゼロ（マルチパスなし）に設定する必要があります。
Including this TLV, with one or the other IF_Num (but not both) set to a non-zero value, in a request message that also includes a Destination Identifier TLV (as described in Section 2.2), is sufficient to identify the "per-interface" MIP in Section 7.3 of [RFC6370].
このTLVを含む、どちらか一方のif_num（両方ではない）をゼロ以外の値に設定し、宛先識別子TLV（セクション2.2で説明する）も含むリクエストメッセージで、「パー - 」を識別するのに十分です。[RFC6370]のセクション7.3のインターフェイス「MIP。
Inclusion of this TLV with both IF_Num fields set to zero would be interpreted as specifying neither an ingress, nor an egress, interface. Note that this is the same as not including the TLV; hence, including this TLV with both IF_Num values set to zero is NOT RECOMMENDED.
このTLVを両方のif_numフィールドにゼロに設定して含めることは、侵入も出口のインターフェースも指定しないと解釈されます。これは、TLVを含めないのと同じであることに注意してください。したがって、両方のif_num値をゼロに設定したこのTLVを含むことは推奨されません。
Including this TLV with both IF_NUM fields set to a non-zero value will result in the responder sending a Return Code of 5 ("Downstream Mapping Mis-match") if either IF_Num is incorrect for this LSP or PW.
両方のif_numフィールドをゼロ以外の値に設定したこのTLVを含めると、if_numがこのLSPまたはPWのいずれかが間違っている場合、RESPONDERが5（「ダウンストリームマッピングミスマッチ」）を送信します。
The format for the identifier TLV is the same for both Source and Destination Identifier TLVs (only the type is different). The format is as specified in the figure below.
識別子TLVの形式は、ソースと宛先識別子TLVの両方で同じです（タイプのみが異なります）。この形式は、以下の図で指定されているとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global_ID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_ID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: New Source/Destination Identifier Format
図3：新しいソース/宛先識別子形式
Type will be one of either 13 or 14, depending on whether the TLV in question is a Source or Destination Identifier TLV.
タイプは、問題のTLVがソースまたは宛先識別子TLVであるかどうかに応じて、13または14のいずれかの1つになります。
Global_ID is as defined in [RFC6370].
Global_idは[RFC6370]で定義されています。
Node_ID is as defined in [RFC6370].
node_idは[RFC6370]で定義されています。
When sending on-demand CV packets using ACH, without IP encapsulation, there MAY be a need to identify the source of the packet. This source identifier (Source ID) will be specified via the Source Identifier TLV, using the Identifier TLV defined in Section 2.2.1, containing the information specified above.
IPカプセル化なしでACHを使用してオンデマンドCVパケットを送信する場合、パケットのソースを特定する必要がある場合があります。このソース識別子（ソースID）は、上記の情報を含むセクション2.2.1で定義された識別子TLVを使用して、ソース識別子TLVを介して指定されます。
An on-demand CV packet MUST NOT include more than one Source Identifier TLV. The Source Identifier TLV MUST specify the identifier of the originator of the packet. If more than one such TLV is present in an on-demand CV request packet, then error 1 (Malformed echo request received; see Section 3.1 of [RFC4379]) MUST be returned, if it is possible to unambiguously identify the source of the packet.
オンデマンドCVパケットには、複数のソース識別子TLVを含めることはできません。ソース識別子TLVは、パケットのオリジネーターの識別子を指定する必要があります。そのようなTLVを複数以上オンデマンドCVリクエストパケットに存在する場合、パケットのソースを明確に識別できる場合は、エラー1（[RFC4379]のセクション3.1を参照）を返す必要があります。。
When sending on-demand CV packets using ACH, without IP encapsulation, there MAY be a need to identify the destination of the packet. This destination identifier (Destination ID) will be specified via the Destination Identifier TLV, using the Identifier TLV defined in Section 2.2.1, containing the information specified above.
IPカプセル化なしでACHを使用してオンデマンドCVパケットを送信する場合、パケットの宛先を識別する必要がある場合があります。この宛先識別子（宛先ID）は、上記の情報を含むセクション2.2.1で定義されている識別子TLVを使用して、宛先識別子TLVを介して指定されます。
An on-demand CV packet MUST NOT include more than one Destination Identifier TLV. The Destination Identifier TLV MUST specify the destination node for the packet. If more than 1 such TLV is present in an on-demand CV Request packet, then error 1 (Malformed echo request received; see Section 3.1 of [RFC4379]) MUST be returned, if it is possible to unambiguously identify the source of the packet.
オンデマンドのCVパケットには、複数の宛先識別子TLVを含めてはなりません。宛先識別子TLVは、パケットの宛先ノードを指定する必要があります。このようなTLVを超えるTLVがオンデマンドCVリクエストパケットに存在する場合、パケットのソースを明確に識別できる場合は、エラー1（[RFC4379]のセクション3.1を参照）を返す必要があります。。
[RFC4379] specifies how an MPLS LSP under test is identified in an echo request. A Target FEC Stack TLV is used to identify the LSP. In order to identify a statically provisioned LSP and PW, new target FEC Stack sub-TLVs are being defined. The new sub-TLVs are assigned sub-type identifiers as follows and are described in the following sections.
[RFC4379]は、ECHOリクエストでMPLS LSPがテスト中のMPLS LSPがどのように識別されるかを指定します。ターゲットFECスタックTLVを使用して、LSPを識別します。静的にプロビジョニングされたLSPおよびPWを識別するために、新しいターゲットFECスタックサブTLVが定義されています。新しいサブTLVには、次のようにサブタイプの識別子が割り当てられ、次のセクションで説明されています。
Type # Sub-Type # Length Value Field
------ ---------- ------ -----------
1 22 24 Static LSP
1 23 32 Static Pseudowire
Figure 4: New Target FEC Sub-Types
図4：新しいターゲットFECサブタイプ
The format of the Static LSP sub-TLV value field is specified in the following figure. The value fields are taken from the definitions in [RFC6370].
静的LSPサブTLV値フィールドの形式は、次の図に指定されています。値フィールドは、[RFC6370]の定義から取得されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Must be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Static LSP FEC Sub-TLV
図5：静的LSP FEC Sub-TLV
The Source Global ID and Destination Global ID MAY be set to zero. When set to zero, the field is not applicable.
ソースグローバルIDおよび宛先グローバルIDは、ゼロに設定できます。ゼロに設定すると、フィールドは適用できません。
The format of the Static PW sub-TLV value field is specified in the following figure.
静的PWサブTLV値フィールドの形式は、次の図に指定されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Service Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Static PW FEC Sub-TLV
図6：静的PW FEC Sub-TLV
The Service Identifier is a 64-bit unsigned integer that is included in the first two words, as shown. The Service Identifier identifies the service associated with the transport path under test. The value MAY, for example, be an Attachment Group Identifier (AGI), type 0x01, as defined in [RFC4446].
サービス識別子は、示されているように、最初の2つの単語に含まれる64ビットの非署名整数です。サービス識別子は、テスト中の輸送パスに関連するサービスを識別します。たとえば、値は、[RFC4446]で定義されているように、アタッチメントグループ識別子（AGI）タイプ0x01である場合があります。
The Source Global ID and Destination Global ID MAY be set to zero. When either of these fields is set to zero, the corresponding Global ID is not applicable. This might be done in a scenario where local scope is sufficient for uniquely identifying services.
ソースグローバルIDおよび宛先グローバルIDは、ゼロに設定できます。これらのフィールドのいずれかがゼロに設定されている場合、対応するグローバルIDは適用されません。これは、サービスを一意に識別するのにローカルスコープで十分であるシナリオで行われる可能性があります。
The Global ID and Node ID fields are defined in [RFC6370]. The AC-ID fields are defined in [RFC5003].
グローバルIDおよびノードIDフィールドは[RFC6370]で定義されています。AC-IDフィールドは[RFC5003]で定義されています。
This section specifies how on-demand CV can be used in the context of MPLS-TP LSPs. The on-demand CV function meets the on-demand connectivity verification requirements specified in [RFC5860], Section 2.2.3. This function SHOULD NOT be performed except in the on-demand mode. This function SHOULD be performed between
このセクションでは、MPLS-TP LSPのコンテキストでオンデマンドCVを使用する方法を指定します。オンデマンドCV関数は、[RFC5860]、セクション2.2.3で指定されているオンデマンド接続検証要件を満たしています。この関数は、オンデマンドモードを除いて実行する必要はありません。この関数は間に実行する必要があります
Maintenance Entity Group End Points (MEPs) and Maintenance Entity Group Intermediate Points (MIPs) of PWs and LSPs, and between End Points of PWs, LSPs, and Sections. In order for the on-demand CV packet to be processed at the desired MIP, the TTL of the MPLS label MUST be set such that it expires at the MIP to be probed.
PWSおよびLSPのメンテナンスエンティティグループエンドポイント（MEP）およびメンテナンスエンティティグループ中間点（MIP）、およびPWS、LSP、およびセクションのエンドポイント間。オンデマンドのCVパケットを目的のMIPで処理するには、MPLSラベルのTTLを設定する必要があり、MIPで有効期限が切れるように設定する必要があります。
[RFC5586] defines an ACH mechanism for MPLS LSPs. The mechanism is a generalization of the Associated Channel mechanism that [RFC4385] defined for use with pseudowires. As a result, it is possible to use a single Associated Channel Type for either an LSP or pseudowire.
[RFC5586]は、MPLS LSPのACHメカニズムを定義します。このメカニズムは、[RFC4385]が擬似動物で使用するために定義された関連チャネルメカニズムの一般化です。その結果、LSPまたはPseudowireのいずれかに単一の関連チャネルタイプを使用することができます。
A new Pseudowire Associated Channel Type (0x0025) is defined for use in performing on-demand connectivity verification. Its use is described in the following sections.
新しい擬似ワイヤ関連チャネルタイプ（0x0025）は、オンデマンド接続の検証を実行するために使用するために定義されています。その使用については、次のセクションで説明します。
ACH TLVs SHALL NOT be associated with this channel type.
ACH TLVは、このチャネルタイプに関連付けられてはなりません。
Except as specifically stated in the sections below, message and TLV construction procedures for on-demand CV messages are as defined in [RFC4379].
以下のセクションに特に記載されている場合を除き、オンデマンドCVメッセージのメッセージとTLVの構築手順は[RFC4379]で定義されています。
LSP ping packets, as specified in [RFC4379], are sent over the MPLS LSP for which OAM is being performed and contain an IP/UDP packet within them. The IP header is not used for forwarding (since LSP forwarding is done using MPLS). The IP header is used mainly for addressing and can be used in the context of MPLS-TP LSPs. This form of on-demand CV OAM MUST be supported for MPLS-TP LSPs when IP addressing is in use.
[RFC4379]で指定されているLSP Pingパケットは、OAMが実行されているMPLS LSPを介して送信され、その中にIP/UDPパケットが含まれています。IPヘッダーは転送には使用されません（LSP転送はMPLSを使用して行われるため）。IPヘッダーは主にアドレス指定に使用され、MPLS-TP LSPのコンテキストで使用できます。IPアドレス指定が使用されている場合、この形式のオンデマンドCV OAMは、MPLS-TP LSPでサポートする必要があります。
The on-demand CV echo response message MUST be sent on the reverse path of the LSP. The reply MUST contain IP/UDP headers followed by the on-demand CV payload. The destination address in the IP header MUST be set to that of the sender of the echo request message. The source address in the IP header MUST be set to a valid address of the replying node.
オンデマンドCVエコー応答メッセージは、LSPの逆パスで送信する必要があります。返信には、IP/UDPヘッダーに続いてオンデマンドCVペイロードが含まれている必要があります。IPヘッダーの宛先アドレスは、Echo要求メッセージの送信者のアドレスに設定する必要があります。IPヘッダーのソースアドレスは、応答ノードの有効なアドレスに設定する必要があります。
IP encapsulated on-demand CV packets MAY be sent over the MPLS LSP using the control channel (ACH). The IP ACH type specified in [RFC4385] MUST be used in such a case. The IP header is used mainly for addressing and can be used in the context of MPLS-TP LSPs.
IPカプセル化されたオンデマンドCVパケットは、コントロールチャネル（ACH）を使用してMPLS LSPを介して送信できます。[RFC4385]で指定されたIP ACHタイプは、そのような場合に使用する必要があります。IPヘッダーは主にアドレス指定に使用され、MPLS-TP LSPのコンテキストで使用できます。
Note that the application-level control channel in this case is the reverse path of the LSP (or Pseudowire) using ACH.
この場合のアプリケーションレベルの制御チャネルは、ACHを使用したLSP（または擬似具）の逆パスであることに注意してください。
The on-demand CV echo response message MUST be sent on the reverse path of the LSP. The response in this case SHOULD use ACH and SHOULD be IP encapsulated.
オンデマンドCVエコー応答メッセージは、LSPの逆パスで送信する必要があります。この場合の応答はAChを使用する必要があり、IPカプセル化する必要があります。
If IP encapsulated, the destination address in the IP header MUST be set to that of the sender of the echo request message, and the source address in the IP header MUST be set to a valid address of the replying node.
IPがカプセル化されている場合、IPヘッダーの宛先アドレスをEcho要求メッセージの送信者の宛先に設定する必要があり、IPヘッダーのソースアドレスを応答ノードの有効なアドレスに設定する必要があります。
The OAM procedures defined in [RFC4379] require the use of IP addressing, and in some cases IP routing, to perform OAM functions.
[RFC4379]で定義されているOAM手順では、OAM関数を実行するために、IPアドレス指定、場合によってはIPルーティングの使用が必要です。
When the ACH header is used, IP addressing and routing is not needed. This section describes procedures for performing on-demand CV without a dependency on IP addressing and routing.
ACHヘッダーを使用する場合、IPアドレス指定とルーティングは必要ありません。このセクションでは、IPアドレス指定とルーティングに依存せずにオンデマンドCVを実行する手順について説明します。
In the non-IP case, when using on-demand CV via LSP ping with the ACH header, the on-demand CV request payload MUST directly follow the ACH header, and the LSP ping Reply mode [RFC4379] in the LSP ping echo request SHOULD be set to 4 (Reply via application level control channel).
非IPケースでは、ACHヘッダーを使用してLSP Pingを介してオンデマンドCVを使用する場合、オンデマンドCVリクエストペイロードはACHヘッダーとLSP Ping EchoリクエストのLSP Ping Replyモード[RFC4379]を直接追跡する必要があります。4に設定する必要があります（アプリケーションレベル制御チャネルを介して返信）。
Note that the application-level control channel in this case is the reverse path of the LSP (or pseudowire) using ACH.
この場合のアプリケーションレベルの制御チャネルは、ACHを使用したLSP（または擬似具）の逆パスであることに注意してください。
The requesting node MAY attach a Source Identifier TLV (Section 2.2) to identify the node originating the request.
要求ノードは、ソース識別子TLV（セクション2.2）を添付して、要求を発信するノードを識別することができます。
If the Reply mode indicated in an on-demand CV Request is 4 (Reply via application level control channel), the on-demand CV reply message MUST be sent on the reverse path of the LSP using ACH. The on-demand CV payload MUST directly follow the ACH header, and IP and/or UDP headers MUST NOT be attached. The responding node MAY attach a Source Identifier TLV to identify the node sending the response.
オンデマンドCV要求に示されている返信モードが4（アプリケーションレベル制御チャネルを介して返信）である場合、ACHを使用してLSPの逆パスでオンデマンドCV返信メッセージを送信する必要があります。オンデマンドCVペイロードはACHヘッダーに直接追跡する必要があり、IPおよび/またはUDPヘッダーを添付してはなりません。応答するノードは、ソース識別子TLVを添付して、応答を送信するノードを識別できます。
If a node receives an MPLS echo request packet over ACH, without IP/ UDP headers, with a reply mode of 4, and if that node does not have a return MPLS LSP path to the echo request source, then the node SHOULD drop the echo request packet and not attempt to send a response.
ノードがMPLSエコーリクエストパケットをACHに受信し、IP/ UDPヘッダーを使用せず、返信モード4を使用し、そのノードにECHO要求ソースへの戻りMPLS LSPパスがない場合、ノードはエコーをドロップする必要がありますパケットを要求し、応答を送信しようとしません。
If a node receives an MPLS echo request with a reply mode other than 4 (Reply via application level control channel), and if the node supports that reply mode, then it MAY respond using that reply mode. If the node does not support the reply mode requested, or is unable to reply using the requested reply mode in any specific instance, the
ノードが4以外の返信モードでMPLSエコー要求を受信した場合（アプリケーションレベル制御チャネルを介して返信）、ノードがその応答モードをサポートする場合、その応答モードを使用して応答する場合があります。ノードが要求された返信モードをサポートしていない場合、または特定のインスタンスで要求された返信モードを使用して返信できない場合、
node MUST drop the echo request packet and not attempt to send a response.
ノードは、エコーリクエストパケットをドロップし、応答を送信しようとしない必要があります。
A new Global flag, Validate Reverse Path (R), is being defined in the LSP ping packet header. When this flag is set in the echo request, the Responder SHOULD return reverse-path FEC information, as described in Section 3.4.2.
新しいグローバルフラグであるLidate Reverse Path（R）は、LSP Pingパケットヘッダーで定義されています。このフラグがエコー要求に設定されている場合、セクション3.4.2で説明されているように、レスポンダーはリバースパスFEC情報を返す必要があります。
The R flag MUST NOT be set in the echo response.
Rフラグをエコー応答に設定してはなりません。
The Global Flags field is now a bit vector with the following format:
グローバルフラグフィールドは、次の形式で少しベクトルになりました。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Global Flags Field
図7：グローバルフラグフィールド
The V flag is defined in [RFC4379]. The T flag is defined in [RFC6425]. The R flag is defined in this document.
Vフラグは[RFC4379]で定義されています。Tフラグは[RFC6425]で定義されています。Rフラグはこのドキュメントで定義されています。
The Validate FEC Stack (V) flag MAY be set in the echo response when reverse-path connectivity verification is being performed.
逆パス接続の検証が実行されている場合、検証型FECスタック（v）フラグは、エコー応答で設定できます。
When the R flag is set in the echo request, the responding node SHOULD attach a Reverse-path Target FEC Stack TLV in the echo response. The requesting node (on receipt of the response) can use the Reverse-path Target FEC Stack TLV to perform reverse-path connectivity verification. For co-routed bidirectional LSPs, the Reverse-path Target FEC Stack used for the on-demand CV will be the same in both the forward and reverse path of the LSP. For associated bidirectional LSPs, the Target FEC Stack MAY be different for the reverse path.
RフラグがECHO要求に設定されている場合、応答するノードはエコー応答でリバースパスターゲットFECスタックTLVを添付する必要があります。要求ノード（応答の受領時）は、リバースパスターゲットFECスタックTLVを使用して、リバースパス接続の検証を実行できます。協調的な双方向LSPの場合、オンデマンドCVに使用される逆パスターゲットFECスタックは、LSPの前方パスとリバースパスの両方で同じになります。関連する双方向LSPの場合、ターゲットFECスタックは逆パスで異なる場合があります。
The format of the Reverse-path Target FEC Stack TLV is the same as that of the Target FEC Stack TLV defined in [RFC4379]. The rules for creating a Target FEC Stack TLV also apply to the Reverse-path Target FEC Stack TLV.
逆パスターゲットFECスタックTLVの形式は、[RFC4379]で定義されているターゲットFECスタックTLVの形式と同じです。ターゲットFECスタックTLVを作成するためのルールは、リバースパスターゲットFECスタックTLVにも適用されます。
Type Meaning
-------- ------------------------------------
16 Reverse-path Target FEC Stack
Figure 8: Reverse-Path Target FEC Stack TLV Type
図8：リバースパスターゲットFECスタックTLVタイプ
On receipt of the echo response, the requesting node MUST perform the following checks:
エコー応答を受け取ったとき、要求ノードは次のチェックを実行する必要があります。
1. Perform interface and label-stack validation to ensure that the packet is received on the reverse path of the bidirectional LSP.
1. インターフェイスとラベルスタックの検証を実行して、双方向LSPの逆パスでパケットが受信されるようにします。
2. If the Reverse-path Target FEC Stack TLV is present in the echo response, then perform FEC validation.
2. エコー応答に逆パスターゲットFECスタックTLVが存在する場合は、FEC検証を実行します。
The verification in this case is performed as described for the Target FEC Stack in Section 3.6 of [RFC4379].
この場合の検証は、[RFC4379]のセクション3.6のターゲットFECスタックについて説明されているように実行されます。
If any of the validations fail, then the requesting node MUST drop the echo response and SHOULD log and/or report an error.
検証のいずれかが失敗した場合、要求ノードはエコー応答をドロップし、エラーを記録および/または報告する必要があります。
[RFC6425] describes how LSP ping can be used for OAM on P2MP LSPs with IP encapsulation. This MUST be supported for MPLS-TP P2MP LSPs when IP addressing is used. When IP addressing is not used, then the procedures described in Section 3.3 can be applied to P2MP MPLS-TP LSPs as well.
[RFC6425]は、IPカプセル化を備えたP2MP LSPのOAMにLSP Pingを使用する方法を説明しています。これは、IPアドレス指定を使用する場合、MPLS-TP P2MP LSPでサポートする必要があります。IPアドレス指定が使用されない場合、セクション3.3で説明されている手順をP2MP MPLS-TP LSPにも適用できます。
Support for on-demand CV on a static MPLS-TP LSP or pseudowire MAY require manageable objects to allow, for instance, configuring operating parameters such as identifiers associated with the statically configured LSP or PW.
静的MPLS-TP LSPまたはPseudowireでのオンデマンドCVのサポートでは、たとえば、静的に構成されたLSPまたはPWに関連付けられた識別子などの動作パラメーターを構成するために管理可能なオブジェクトが必要になる場合があります。
The specifics of this manageability requirement are out-of-scope in this document and SHOULD be addressed in appropriate management specifications.
この管理要件の詳細は、このドキュメントではスコープ外であり、適切な管理仕様で対処する必要があります。
At the Requester, when encapsulating the LSP echo request (LSP ping) packet (with the IP ACH, or the Non IP ACH, codepoint), a GAL MUST be added before adding the MPLS LSP label, and sending the LSP Ping echo request packet in-band in the MPLS LSP.
リクエスターでは、LSPエコーリクエスト（LSP Ping）パケット（IP ACHまたは非IP ACH、コードポイントを使用）をカプセル化する場合、MPLS LSPラベルを追加してLSP Ping Echoリクエストパケットを送信する前にGALを追加する必要があります。MPLS LSPのバンド。
The GAL MUST NOT be considered as part of the MPLS label stack that requires verification by the Responder. For this reason, a Nil FEC TLV MUST NOT be added or associated with the GAL.
GALは、応答者による検証が必要なMPLSラベルスタックの一部と見なされてはなりません。このため、NIL FEC TLVをGALに追加したり関連付けたりしてはなりません。
The GAL MUST NOT be included in DSMAP or DDMAP TLVs.
GALは、DSMAPまたはDDMAP TLVSに含めてはなりません。
Interface and Label Stack TLVs MUST include the whole label stack including the GAL.
インターフェイスとラベルスタックTLVには、GALを含むラベルスタック全体を含める必要があります。
This section specifies how on-demand CV route tracing can be used in the context of MPLS-TP LSPs. The on-demand CV route tracing function meets the route tracing requirement specified in [RFC5860], Section 2.2.3.
このセクションでは、MPLS-TP LSPのコンテキストでオンデマンドCVルートトレースを使用する方法を指定します。オンデマンドCVルートトレース機能は、[RFC5860]、セクション2.2.3で指定されたルートトレース要件を満たしています。
This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections.
この関数は、オンデマンドで実行する必要があります。この関数は、PWSとLSPのエンドポイントと中間点、およびPWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
When performing on-demand CV route tracing, the requesting node inserts a Downstream Mapping TLV to get the downstream node information and to enable LSP verification along the transit nodes. The Downstream Mapping TLV can be used as is for performing route tracing. If IP addressing is not in use, then the Address Type field in the Downstream Mapping TLV can be set to "Non IP" (Section 2.1). The Downstream Mapping TLV address type field can be extended to include other address types as needed.
オンデマンドCVルートトレースを実行するとき、要求ノードはダウンストリームマッピングTLVを挿入して、ダウンストリームノード情報を取得し、トランジットノードに沿ったLSP検証を有効にします。ダウンストリームマッピングTLVは、ルートトレースを実行するために使用できます。IPアドレス指定が使用されていない場合、下流マッピングTLVのアドレスタイプフィールドを「非IP」（セクション2.1）に設定できます。ダウンストリームマッピングTLVアドレスタイプフィールドは、必要に応じて他のアドレスタイプを含めるように拡張できます。
The mechanics of on-demand CV route tracing are similar to those described for ping in Section 3.1. On-demand route tracing packets sent by the Requester MUST follow procedures described in [RFC4379]. This form of on-demand CV OAM MUST be supported for MPLS-TP LSPs, when IP addressing is used.
オンデマンドCVルートトレースのメカニズムは、セクション3.1でPINGについて説明したものと似ています。要求者が送信したオンデマンドルートトレースパケットは、[RFC4379]に記載されている手順に従う必要があります。IPアドレス指定を使用する場合、この形式のオンデマンドCV OAMは、MPLS-TP LSPでサポートする必要があります。
This section describes procedures for performing LSP route tracing when using LSP ping with the ACH header and without any dependency on IP addressing. The procedures specified in Section 3.3 with regards to the Source Identifier TLV apply to LSP route tracing as well.
このセクションでは、ACHヘッダーを使用してLSP Pingを使用し、IPアドレスに依存せずにLSPルートトレースを実行する手順について説明します。ソース識別子TLVに関してセクション3.3で指定された手順も、LSPルートトレースに適用されます。
On-demand route tracing packets sent by the Requester MUST adhere to the format described in Section 3.3. MPLS-TTL expiry (as described in [RFC4379]) will be used to direct the packets to specific nodes along the LSP path.
要求者によって送信されたオンデマンドルートトレースパケットは、セクション3.3で説明されている形式に準拠する必要があります。MPLS-TTL有効期限（[RFC4379]で説明されているように）を使用して、LSPパスに沿って特定のノードにパケットを向けるために使用されます。
The on-demand CV route tracing responses will be received on the LSP itself, and the presence of an ACH header with channel type of on-demand CV is an indicator that the packet contains an on-demand CV payload.
オンデマンドCVルートトレース応答はLSP自体で受信され、チャネルタイプのオンデマンドCVを備えたACHヘッダーの存在は、パケットにオンデマンドCVペイロードが含まれていることを示す指標です。
When an echo request reaches the Responder, the presence of the ACH channel type of on-demand CV will indicate that the packet contains on-demand CV data. The on-demand CV data, the label stack, and the destination identifier are sufficient to identify the LSP associated with the echo request packet. If there is an error and the node is unable to identify the LSP on which the echo response would be sent, the node MUST drop the echo request packet and not send any response back. All responses MUST always be sent on an LSP path using the ACH header and ACH channel type of on-demand CV.
エコーリクエストがレスポンダーに到達すると、オンデマンドCVのACHチャネルタイプの存在は、パケットにオンデマンドCVデータが含まれていることを示します。オンデマンドCVデータ、ラベルスタック、および宛先識別子は、ECHO要求パケットに関連付けられたLSPを識別するのに十分です。エラーがあり、ノードがエコー応答が送信されるLSPを識別できない場合、ノードはエコーリクエストパケットをドロップし、応答を送信しないでください。すべての応答は、ACHヘッダーとACHチャネルタイプのオンデマンドCVを使用して、常にLSPパスで送信する必要があります。
[RFC6425] describes how LSP ping can be used for OAM on P2MP LSPs. This MUST be supported for MPLS-TP P2MP LSPs when IP addressing is used. When IP addressing is not used, then the procedures described in Section 4.2 can be applied to P2MP MPLS-TP LSPs as well.
[RFC6425]は、P2MP LSPのOAMにLSP pingを使用する方法を説明しています。これは、IPアドレス指定を使用する場合、MPLS-TP P2MP LSPでサポートする必要があります。IPアドレス指定が使用されない場合、セクション4.2で説明されている手順をP2MP MPLS-TP LSPにも適用できます。
On-demand CV using ACH SHOULD NOT be used when there is ECMP (Equal Cost Multi-Path) for a given LSP. The inclusion of the additional ACH header can modify the hashing behavior for OAM packets that could result in incorrect monitoring of the path taken by data traffic.
特定のLSPにECMP（等しいコストマルチパス）がある場合は、ACHを使用したオンデマンドCVを使用しないでください。追加のACHヘッダーを含めると、データトラフィックがとるパスの誤った監視をもたらす可能性のあるOAMパケットのハッシュ挙動を変更できます。
The procedures specified in this document for non-IP encapsulation apply to MPLS-TP transport paths. This includes LSPs and PWs when IP encapsulation is not desired. However, when IP addressing is used, as in non MPLS-TP LSPs, procedures specified in [RFC4379] MUST be used.
このドキュメントで指定された非IPカプセル化の手順は、MPLS-TPトランスポートパスに適用されます。これには、IPカプセル化が望ましくない場合のLSPとPWが含まれます。ただし、非MPLS-TP LSPのようにIPアドレス指定を使用する場合、[RFC4379]で指定された手順を使用する必要があります。
This document does not itself introduce any new security considerations. Those discussed in [RFC4379] are applicable to this document.
このドキュメント自体は、新しいセキュリティ上の考慮事項を導入していません。[RFC4379]で説明されているものは、このドキュメントに適用できます。
Unlike typical deployment scenarios identified in [RFC4379], however, likely deployments of on-demand CV for transport paths involves a strong possibility that the techniques in this document may be used across MPLS administrative boundaries. Where this may occur, it is RECOMMENDED that on-demand OAM is configured as necessary to ensure that Source Identifier TLVs are included in on-demand CV messages. This will allow implementations to filter OAM messages arriving from an unexpected or unknown source.
ただし、[RFC4379]で特定された典型的な展開シナリオとは異なり、輸送パスのオンデマンドCVの展開には、このドキュメントの手法がMPLS管理境界全体で使用できる可能性があります。これが発生する場合は、ソース識別子TLVがオンデマンドCVメッセージに含まれることを確認するために、オンデマンドOAMを必要に応じて構成することをお勧めします。これにより、実装が予期しないソースまたは未知のソースから到着するOAMメッセージをフィルタリングできます。
IANA has assigned the following TLV types from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry (from the "Standards Action" TLV type range):
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）PINGパラメーター」レジストリ、「TLVS、およびサブTLV「サブレジストリ」（「標準アクション」TLVタイプ範囲から）から次のTLVタイプを割り当てました。：
Length
Type # TLV Name Octets Reference
------ ----------------- ------ ---------------------------
13 Source ID 8 this document (Section 2.2)
14 Destination ID 8 this document (Section 2.2)
Figure 9: New Source and Destination Identifier TLV Types
図9：新しいソースおよび宛先識別子TLVタイプ
Section 2.3 defines 2 new sub-TLV types for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (1).
セクション2.3では、LSP Ping [RFC4379]ターゲットFECスタックTLV（1）に含めるための2つの新しいサブTLVタイプを定義します。
IANA has assigned sub-type values to the following sub-TLVs from the "Multi-Protocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANAは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルスイッチドパス（LSP）PINGパラメーター「TLVS、およびSub-TLVS」サブレジストリからサブタイプの値を次のサブTLVに割り当てました。
Value Meaning Reference
----- ------------------- -----------------------------
22 Static LSP this document (Section 2.4.1)
23 Static Pseudowire this document (Section 2.4.2)
Section 3.4.2 defines a new TLV type for inclusion in the LSP ping packet.
セクション3.4.2は、LSP Pingパケットに含めるための新しいTLVタイプを定義しています。
IANA has assigned a type value to the TLV from the "Multi-Protocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANAは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルスイッチパス（LSP）PINGパラメーター」レジストリ、「TLV、およびサブTLV」サブレジストリからタイプ値をTLVに割り当てました。
Type Meaning Reference
----- -------------------------- ---------------------------
16 Reverse-path Target FEC this document (Section 3.4)
Stack TLV
The sub-TLV space and assignments for this TLV will be the same as that for the Target FEC Stack TLV. Sub-types for the Target FEC Stack TLV and the Reverse-path Target FEC Stack TLV MUST be kept the same. Any new sub-type added to the Target FEC Stack TLV MUST apply to the Reverse-path Target FEC Stack TLV as well.
このTLVのサブTLVスペースと割り当ては、ターゲットFECスタックTLVのスペースと同じです。ターゲットFECスタックTLVおよびリバースパスターゲットFECスタックTLVのサブタイプは、同じ保持する必要があります。ターゲットFECスタックTLVに追加された新しいサブタイプは、リバースパスターゲットFECスタックTLVにも適用する必要があります。
On-demand connectivity verification requires a unique Associated Channel Type. IANA has assigned a PW ACH Type from the "Pseudowire Associated Channel Types" registry as described below:
オンデマンド接続検証には、一意の関連チャネルタイプが必要です。IANAは、以下に説明する「Pseudowire関連チャネルタイプ」レジストリからPW ACHタイプを割り当てました。
Value Description TLV Follows Reference
------ ------------- ----------- -------------------------
0x0025 On-Demand CV No this document (Section 3)
ACH TLVs SHALL NOT be associated with this channel type.
ACH TLVは、このチャネルタイプに関連付けられてはなりません。
[RFC4379] defined several registries. It also defined some value assignments without explicitly asking for IANA to create a registry to support additional value assignments. One such case is in defining address types associated with the Downstream Mapping (DSMAP) TLV.
[RFC4379]はいくつかのレジストリを定義しました。また、IANAが追加の価値の割り当てをサポートするレジストリを作成するように明示的に求めることなく、いくつかの価値の割り当てを定義しました。そのようなケースの1つは、ダウンストリームマッピング（DSMAP）TLVに関連付けられたアドレスタイプを定義することです。
This document extends RFC 4379 by defining a new address type for use with the Downstream Mapping and Downstream Detailed Mapping TLVs.
このドキュメントは、ダウンストリームマッピングおよびダウンストリーム詳細マッピングTLVで使用する新しいアドレスタイプを定義することにより、RFC 4379を拡張します。
Recognizing that the absence of a registry makes it possible to have collisions of "address-type" usages, IANA has established a new registry -- associated with both [RFC4379] and this document -- that initially allocates the following assignments:
レジストリがないことにより、「アドレスタイプ」使用法の衝突が可能になることを認識して、IANAは次の割り当てを最初に割り当てる[RFC4379]とこの文書の両方に関連する新しいレジストリを確立しました。
Type # Address Type K Octets Reference
------ ------------ -------- --------------------------
1 IPv4 Numbered 16 RFC 4379
2 IPv4 Unnumbered 16 RFC 4379
3 IPv6 Numbered 40 RFC 4379
4 IPv6 Unnumbered 28 RFC 4379
5 Non IP 12 this document (Sect. 2.1.1)
Downstream Mapping Address Type Registry
ダウンストリームマッピングアドレスタイプレジストリ
Because the field in this case is an 8-bit field, the allocation policy for this registry is "Standards Action."
この場合のフィールドは8ビットフィールドであるため、このレジストリの割り当てポリシーは「標準アクション」です。
The following individuals contributed materially to this document:
次の個人がこの文書に実質的に貢献しました。
o Thomas D. Nadeau, CA Technologies
o トーマスD.ナドー、カリフォルニアテクノロジーズ
o Nurit Sprecher, Nokia Siemens Networks
o Nurit Sprecher、Nokia Siemens Networks
o Yaacov Weingarten, Nokia Siemens Networks
o Yaacov Weingarten、Nokia Siemens Networks
In addition, we would like to thank the following individuals for their efforts in reviewing and commenting on the document:
さらに、ドキュメントについてレビューしてコメントする努力について、以下の個人に感謝したいと思います。
o Adrian Farrel
o エイドリアン・ファレル
o Alexander Vaishtein
o アレクサンダー・ヴァイシュテイン
o David Sinicrope (Routing Directorate)
o David Sinicrope（ルーティングディレクター）
o Greg Mirsky
o グレッグ・ミルスキー
o Hideki Endo
o hideki endo
o Huub van Helvoort
o Huub Van Helvoort
o Joel Halpern (Routing Directorate)
o Joel Halpern（ルーティングディレクター）
o Loa Andersson
o ロア・アンダーソン
o Mach Chen
o マッハチェン
o Mahesh Akula
o マヘシュアクラ
o Sam Aldrin
o サム・アルドリン
o Sandra Murphy (Security Directorate)
o サンドラマーフィー（セキュリティ局）
o Yaacov Weingarten
o Yaacov Weingarten
o Yoshinori Koike
o ヨシノリ・コイク
o Zhenlong Cui
o Zhenlong Cui
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Vigoureux、M。、およびS. Bryant、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS輸送プロファイル（MPLS-TP）識別子」、RFC 6370、2011年9月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424] Bahadur、N.、Kompella、K。、およびG. Swallow、「MPLSトンネル上でラベルスイッチパスping（LSP ping）を実行するメカニズム」、RFC 6424、2011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Swallow、G.、Ali、Z.、Farrel、A.、Yasukawa、S.、およびT. Nadeau、「ポイントツーマルチポイントMPLSのデータ平面障害の検出 - LSPへの拡張Ping」、RFC 6425、2011年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「集約のためのアタッチメント個体識別子（AII）タイプ」、RFC 5003、2007年9月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ward、D。、およびM. Betts、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I。およびD. Allan、「MPLSベースの輸送ネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、2011年9月。
Authors' Addresses
著者のアドレス
Eric Gray Ericsson 900 Chelmsford Street Lowell, MA 01851 US
エリック・グレイ・エリクソン900チェルムスフォード・ストリート・ローウェル、マサチューセッツ州01851米国
Phone: +1 978 275 7470
EMail: eric.gray@ericsson.com
Nitin Bahadur Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
Nitin Bahadur Juniper Networks、Inc。1194 N. Mathilda Avenue Sunnyvale、CA 94089 US
Phone: +1 408 745 2000
EMail: nitinb@juniper.net
URI: www.juniper.net
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 US
Sami Boutros Cisco Systems、Inc。3750 Cisco Way San Jose、CA 95134 US
EMail: sboutros@cisco.com
Rahul Aggarwal
Rahul Aggarwal
EMail: raggarwa_1@yahoo.com