Internet Engineering Task Force (IETF) N. Bahadur
Request for Comments: 6424 K. Kompella
Updates: 4379 Juniper Networks, Inc.
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
November 2011
Mechanism for Performing Label Switched Path Ping (LSP Ping)
over MPLS Tunnels
Abstract
抽象
This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs.
この文書では、MPLSトンネル上とステッチMPLSラベルのtracerouteのためのLSP（RFC 4379で指定）のping tracerouteを実行するための方法を説明すると、スイッチパス（LSP）。 RFC 4379に概説された技術は、他のMPLSトンネルを介して、または縫合LSPについてもLSPのためにトレースルート転送等価クラス（FEC）の検証及び経路探索を行うには不十分です。この文書は、この文書で概説他の手順とともに、そのようなLSPを追跡するために使用することができ、新たなTLVを支持する（RFC 4379で定義された）ダウンストリームマッピングTLVを非難します。
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/rfc6424.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6424で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return Code per Downstream . . . . . . . . . . . . . . 6
3.2.2. Return Code for Stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7
3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1.1. Multipath Data Sub-TLV . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13
4. Performing MPLS Traceroute on Tunnels . . . . . . . . . . . . 13
4.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 13
4.1.1. Addition of a New Tunnel . . . . . . . . . . . . . . . 13
4.1.2. Transition between Tunnels . . . . . . . . . . . . . . 14
4.1.3. Modification to FEC Validation Procedure on Transit . 16
4.2. Modification to FEC Validation Procedure on Egress . . . . 16
4.3. Ingress Node Procedure . . . . . . . . . . . . . . . . . . 17
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1.1. Stack Change Sub-TLV Not Present . . . . . . . . . 17
4.3.1.2. Stack Change Sub-TLV(s) Present . . . . . . . . . 17
4.3.2. Modifications to Handling a Return Code 3 Reply. . . . 19
4.3.3. Handling of New Return Codes . . . . . . . . . . . . . 19
4.4. Handling Deprecated Downstream Mapping TLV . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22
This documents describes methods for performing LSP ping (specified in [RFC4379]) traceroute over MPLS tunnels. The techniques in [RFC4379] outline a traceroute mechanism that includes Forwarding Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) path discovery. Those mechanisms are insufficient and do not provide details when the FEC being traced traverses one or more MPLS tunnels and when Label Switched Path (LSP) stitching [RFC5150] is in use. This document deprecates the Downstream Mapping TLV [RFC4379], introducing instead a new TLV that is more extensible and that enables retrieval of detailed information. Using the new TLV format along with the existing definitions of [RFC4379], this document describes procedures by which a traceroute request can correctly traverse MPLS tunnels with proper FEC and label validations.
このドキュメントは、MPLSトンネル上のLSP（[RFC4379]で指定）のping tracerouteを実行するための方法を記載しています。 [RFC4379]での技術は、転送等価クラス（FEC）の検証と等価コストマルチパス（ECMP）経路発見を含むルートトレース機構を概説します。これらのメカニズムは不十分であり、トレースされているFECは、1つ以上のMPLSトンネルを横断するときにラベルスイッチパス（LSP）ステッチ[RFC5150]が使用されているときの詳細を提供しません。この文書は、代わりに、より拡張可能であり、それは詳細情報の検索を可能にする新しいTLVを導入し、下流マッピングTLV [RFC4379]を非難します。 [RFC4379]の既存の定義と一緒に新しいTLV形式を使用して、このドキュメントは、トレースルート要求が正しく、適切なFECとラベル検証してMPLSトンネルを通過することが可能な手順を説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
An LSP ping traceroute may cross multiple MPLS tunnels en route to the destination. Let us consider a simple case.
LSPピングトレースルートは、目的地への途中で複数のMPLSトンネルを横断してもよいです。私たちは、単純なケースを考えてみましょう。
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
Figure 1: LDP over RSVP Tunnel
図1：RSVPトンネル経由でLDP
When a traceroute is initiated from router A, router B returns downstream mapping information for node C in the MPLS echo reply. The next MPLS echo request reaches router C with an LDP FEC. Node C is a pure RSVP node and does not run LDP. Node C will receive the MPLS echo request with two labels but only one FEC in the Target FEC stack. Consequently, node C will be unable to perform a complete FEC validation. It will let the trace continue by just providing next-hop information based on the incoming label, and by looking up the forwarding state associated with that label. However, ignoring FEC validation defeats the purpose of control-plane validations. The
トレースルートは、ルータAから開始されたときに、ルータBは、MPLSエコー応答におけるノードCの下流マッピング情報を返します。次のMPLSエコー要求は、LDP FECとルータCに到達します。ノードCは、純粋なRSVPノードであり、LDPを実行しません。ノードCは、ターゲットFECスタックにMPLSエコー2つのラベルを持つ要求だけで1つのFECを受け取ることになります。結果として、ノードCは、完全なFEC検証を実行することができません。それは、そのラベルに関連付けられた転送状態を調べることにより、トレースがちょうど着信ラベルに基づいて、ネクストホップ情報を提供することで、継続できるようになります。しかし、FECの検証を無視することはコントロールプレーンの検証の目的に反し。ザ・
MPLS echo request should contain sufficient information to allow node C to perform FEC validations to catch any misrouted echo requests.
MPLSエコー要求は、任意の正しくルーティングされなかっエコー要求をキャッチするためにFEC検証を実行するノードCを可能にするのに十分な情報が含まれている必要があります。
The above problem can be extended for a generic case of hierarchical tunnels or stitched tunnels (e.g., B-C can be a separate RSVP tunnel and C-D can be a separate RSVP tunnel). The problem of FEC validation for tunnels can be solved if the transit routers (router B in the above example) provide some information to the ingress regarding the start of a new tunnel.
上記の問題は、階層トンネルまたはステッチトンネルの一般的な場合に拡張することができる（例えば、B-Cは、別々のRSVPのトンネルすることができ、C-Dは、独立したRSVPのトンネルであることができます）。トランジットルータ（上記の例では、ルータB）は、新しいトンネルの開始に関する進入するためにいくつかの情報を提供する場合トンネルのFEC検証の問題を解決することができます。
Stitched LSPs involve two or more LSP segments stitched together. The LSP segments can be signaled using the same or different signaling protocols. In order to perform an end-to-end trace of a stitched LSP, the ingress needs to know FEC information regarding each of the stitched LSP segments. For example, consider the figure below.
ステッチLSPは縫合二つ以上のLSPセグメントを含みます。 LSPセグメントは、同じまたは異なるシグナリングプロトコルを用いてシグナリングすることができます。ステッチLSPのエンドツーエンドのトレースを実行するために、入口は、縫合LSPセグメントの各々についてのFEC情報を知る必要があります。たとえば、次の図を検討します。
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 2: Stitched LSP
図2：LSPステッチ
Consider ingress (A) tracing end-to-end stitched LSP A--F. When an MPLS echo request reaches router C, there is a FEC stack change happening at router C. With current LSP ping [RFC4379] mechanisms, there is no way to convey this information to A. Consequently, when the next echo request reaches router D, router D will know nothing about the LDP FEC that A is trying to trace.
Fを - 入力（A）エンドツーエンドのLSP Aステッチトレースを考えます。 MPLSエコー要求は、ルータCに到達すると、現在のLSPピングとルータCで起こっFECスタック変化は[RFC4379]メカニズム、次のエコー要求は、ルータDに達したとき、その結果Aにこの情報を伝達する方法はありません、ルータDは、Aが追跡しようとしているLDP FECについて何も知らないだろう。
Thus, the procedures defined in [RFC4379] do not make it possible for the ingress node to:
したがって、[RFC4379]で定義された手順は、に入口ノードのことを可能にしません。
In many cases, there is a need to associate additional data in the MPLS echo reply. In most cases, the additional data needs to be associated on a per-downstream-neighbor basis. Currently, the MPLS echo reply contains one Downstream Mapping TLV (DSMAP) per downstream neighbor. However, the DSMAP format is not extensible; hence, it is not possible to associate more information with a downstream neighbor. This document defines a new extensible format for the DSMAP and provides mechanisms for solving the tunneled LSP ping problem using the new format. In summary, this document makes the following TLV changes:
多くの場合、MPLSエコー応答に追加のデータを関連付ける必要があります。ほとんどの場合、追加のデータごとの下流の隣人ベースで関連付ける必要があります。現在、MPLSエコー応答は、下流の隣人ごとに1つのダウンストリームマッピングTLV（DSMAP）が含まれています。しかし、DSMAPフォーマットは拡張可能ではありません。したがって、下流の隣人とのより多くの情報を関連付けることはできません。この文書は、DSMAPための新しい拡張可能なフォーマットを定義し、新しい形式を使用してトンネリングLSPピングの問題を解決するためのメカニズムを提供します。要約すると、この文書は、次のTLVの変更を行います。
o Addition of new Downstream Detailed Mapping TLV (DDMAP).
O新しい川下詳細なマッピングTLVの追加（DDMAP）。
o Deprecation of existing Downstream Mapping TLV (DSMAP).
O既存のダウンストリームマッピングTLV（DSMAP）の廃止。
o Addition of Downstream FEC stack change sub-TLV to DDMAP.
O DDMAPへのダウンストリームFECスタック切り替えサブTLVの追加。
A new Return Code is being defined "See DDM TLV for Return Code and Return Subcode" (Section 6.3) to indicate that the Return Code is per Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST be used only in the message header and MUST be set only in the MPLS echo reply message. If the Return Code is set in the MPLS echo request message, then it MUST be ignored. When this Return Code is set, each Downstream Detailed Mapping TLV MUST have an appropriate Return Code and Return Subcode. This Return Code MUST be used when there are multiple downstreams for a given node (such as Point to Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node needs to return a Return Code/Return Subcode for each downstream. This Return Code MAY be used even when there is only one downstream for a given node.
新しいリターンコードがリターンコードが川下の詳細なマッピングTLV（3.3節）ごとであることを示すために（6.3節）、「リターンコードとリターンサブコードのためのDDM TLVを参照してください」に定義されています。この戻りコードは、メッセージヘッダで使用されなければならないだけMPLSエコー応答メッセージに設定されなければなりません。リターンコードがMPLSエコー要求メッセージに設定されている場合は、それを無視しなければなりません。このリターンコードが設定されている場合は、各ダウンストリームの詳細なマッピングTLVは、適切なリターンコードとリターンサブコードを持たなければなりません。 （例えばマルチ（P2MPにポイント）または等価コストマルチパス（ECMP）のような）所与のノードのための複数のダウンストリームが存在する場合、このリターンコードを使用しなければなりません、そして、ノードは、それぞれ下流のリターンコード/リターンサブコードを返す必要があります。指定されたノードのための唯一のダウンストリームがある場合でも、このリターンコードを使用することができます。
When a traceroute is being performed on stitched LSPs (Section 4.1.2), the stitching point SHOULD indicate the stitching action to the node performing the trace. This is done by setting the Return Code to "Label switched with FEC change" (Section 6.3). If a node is performing FEC hiding, then it MAY choose to set the Return Code to a value (specified in [RFC4379]) other than "Label switched with FEC change". The Return Code "Label switched with FEC change" MUST NOT be used if no FEC stack sub-TLV (Section 3.3.1.3) is present in the Downstream Detailed Mapping TLV(s). This new Return Code MAY be used for hierarchical LSPs (for indicating the start or end of an outer LSP).
トレースルートは、ステッチのLSP（セクション4.1.2）上で実行されているとき、縫合ポイントは、トレースを実行するノードに縫い動作を示すべきです。これは、（6.3節）「ラベルはFEC変化に切り替え」に戻りコードを設定することによって行われます。ノードがFECの隠蔽を実行している場合、それは（[RFC4379]で指定）以外の「ラベルはFEC変化に切り替える」の値に戻りコードを設定するために選ぶかもしれません。リターンコード「ラベルはFEC変化に切り替え、」何のFECスタックのサブTLV（セクション3.3.1.3）は川下の詳細なマッピングTLV（複数可）に存在しない場合に使用してはいけません。この新たな戻りコードは、（外側のLSPの開始または終了を指示するための）階層のLSPのために使用されるかもしれません。
Type # Value Field
------ ------------
20 Downstream Detailed Mapping
20下流詳細マッピング
The Downstream Detailed Mapping object is a TLV that MAY be included in an MPLS echo request message. Only one Downstream Detailed Mapping object may appear in an echo request. The presence of a Downstream Detailed Mapping object is a request that Downstream Detailed Mapping objects be included in the MPLS echo reply. If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded.
下流詳細なマッピングオブジェクトは、MPLSエコー要求メッセージに含まれるかもしれTLVです。唯一のダウンストリームの詳細なマッピングオブジェクトは、エコー要求に表示される場合があります。下流詳細なマッピングオブジェクトの存在は下流の詳細なマッピングオブジェクトはMPLSエコー応答に含まれる要求です。返答ルータがFECの先（ラベルエッジルータ）である場合には、川下詳細なマッピングTLVは、MPLSエコー応答に含まれるべきではありません。そうでなければ、応答ルータは、このFECを転送することができ、その上、各インターフェイスのダウンストリーム詳細なマッピング・オブジェクトが含まれるべきです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-tlv Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Downstream Detailed Mapping TLV
図3：下流詳細マッピングTLV
The Downstream Detailed Mapping TLV format is derived from the Downstream Mapping TLV format. The key change is that variable length and optional fields have been converted into sub-TLVs. The fields have the same use and meaning as in [RFC4379]. A summary of the fields taken from the Downstream Mapping TLV is as below:
下流詳細マッピングTLVフォーマットは、下流マッピングTLVフォーマットから導出されます。キー変更は、可変長とオプションフィールドは、サブのTLVに変換されていることです。フィールドは、[RFC4379]と同様に使用して意味を持ちます。川下のマッピングTLVから取り出したフィールドの概要は以下の通りです：
Maximum Transmission Unit (MTU)
最大転送単位（MTU）
The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream Label Switching Router (LSR).
MTUは、ダウンストリームラベルスイッチングルータ（LSR）へのインタフェースに収まる（ラベルスタックを含む）最大のMPLSフレームのオクテットサイズです。
Address Type
アドレスタイプ
The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields.
インターフェースは、番号または番号なしの場合はアドレスタイプを示します。また、ダウンストリームIPアドレスとダウンストリームインターフェイスフィールドの長さを決定します。
DS Flags
DSフラグ
The DS Flags field is a bit vector of various flags.
DSのFlagsフィールドは様々なフラグのビットベクトルです。
Downstream Address and Downstream Interface Address
下流の住所と下流のインターフェイスアドレス
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. For details regarding setting the address value, refer to [RFC4379].
IPv4アドレスとインターフェイスインデックスが4つのオクテットで符号化されます。 IPv6アドレスは16個のオクテットでエンコードされています。アドレス値の設定に関する詳細については、[RFC4379]を参照してください。
The newly added sub-TLVs and their fields are as described below.
新たに追加されたサブのTLV及びそれらのフィールドは以下のように記載されています。
Return Code
リターンコード
The Return Code is set to zero by the sender. The receiver can set it to one of the values specified in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry.
リターンコードは、送信者によってゼロに設定されています。受信機がで指定された値のいずれかに設定することができ、レジストリのサブレジストリ「リターンコード」、「マルチプロトコルラベルスイッチング（MPLS）ラベルはパス（LSPの）Pingのパラメータ交換しました」。
If the receiver sets a non-zero value of the Return Code field in the Downstream Detailed Mapping TLV, then the receiver MUST also set the Return Code field in the echo reply header to "See DDM TLV for Return Code and Return Subcode" (Section 6.3). An exception to this is if the receiver is a bud node [RFC4461] and is replying as both an egress and a transit node with a Return Code of 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") in the echo reply header.
受信機は、ダウンストリームの詳細なマッピングTLVに戻りコードフィールドの非ゼロ値を設定した場合、受信機は、「リターンコードとリターンサブコードのためのDDM TLVを見る」ためにエコー応答ヘッダに戻りコードフィールドを設定しなければならない（セクション6.3）。受信機は、芽ノード[RFC4461]であり、出口3の戻りコードを有するトランジットノードの両方として返信された場合、この例外は、「ルータを返信するスタック深さでのFECのための出口である<RSC>」（あります）エコー応答ヘッダです。
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Code specified in the Downstream Detailed Mapping TLV MUST be ignored.
エコー応答メッセージのリターンコードは、いずれかの「戻りコードとリターンサブコードのためのDDM TLVを参照してください」（セクション6.3）に設定されていない場合、または「ルータを返信する<RSC>スタック深さでFECのための出口である」、そして、リターンコードは、TLVを無視しなければなりません川下詳細なマッピングで指定されました。
Return Subcode
リターンサブコード
The Return Subcode is set to zero by the sender. The receiver can set it to one of the values specified in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry. This field is filled in with the stack-depth for those codes that specify the stack-depth. For all other codes, the Return Subcode MUST be set to zero.
リターンサブコードは、送信者によってゼロに設定されています。受信機がで指定された値のいずれかに設定することができ、レジストリのサブレジストリ「リターンコード」、「マルチプロトコルラベルスイッチング（MPLS）ラベルはパス（LSPの）Pingのパラメータ交換しました」。このフィールドは、スタックの深さを指定し、それらのコードのスタック深さで充填されています。他のすべてのコードの場合、リターン・サブコードをゼロに設定しなければなりません。
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Subcode specified in the Downstream Detailed Mapping TLV MUST be ignored.
エコー応答メッセージのリターンコードは、いずれかの「戻りコードとリターンサブコードのためのDDM TLVを参照してください」（セクション6.3）に設定されていない場合、または「ルータを返信する<RSC>スタック深さでFECのための出口である」、そして、川下詳細なマッピングTLVで指定されたサブコードを返しますが無視しなければなりません。
Sub-tlv Length
サブTLVの長さ
Total length in bytes of the sub-TLVs associated with this TLV.
このTLVに関連したサブのTLVのバイト単位の全長。
This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Mapping TLV.
このセクションでは、下流詳細マッピングTLVの一部として含まれ得るサブTLVを定義します。
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Multipath Sub-TLV
図4：マルチサブTLV
The multipath data sub-TLV includes Multipath Information. The sub-TLV fields and their usage is as defined in [RFC4379]. A brief summary of the fields is as below:
マルチパスデータサブTLVは、マルチパスの情報が含まれています。サブTLVフィールドおよびその使用方法は、[RFC4379]で定義される通りです。フィールドの概要は以下の通りです：
Multipath Type
マルチタイプ
The type of the encoding for the Multipath Information.
マルチパス情報のエンコードの種類。
Multipath Length
マルチパスの長さ
The length in octets of the Multipath Information.
マルチパス情報のオクテットの長さ。
MBZ
QN
MUST be set to zero when sending; MUST be ignored on receipt.
送信する際に、ゼロに設定しなければなりません。領収書で無視しなければなりません。
Multipath Information
マルチインフォメーション
Encoded multipath data, according to the Multipath Type.
マルチパスの種類に応じて、マルチパスデータをエンコード。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Label Stack Sub-TLV
図5：ラベルスタックサブTLV
The Label stack sub-TLV contains the set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. The number of label/protocol pairs present in the sub-TLV is determined based on the sub-TLV data length. The label format and protocol type are as defined in [RFC4379]. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be included.
このルータは、このインターフェイスを介してパケットを転送した場合、それは登場していたとして、ラベルスタックサブTLVはラベルスタックのラベルのセットが含まれています。暗黙的ヌルラベルは、明示的に含まれています。サブTLVに存在するラベル/プロトコルのペアの数は、サブTLVデータ長に基づいて決定されます。 [RFC4379]で定義されるようにラベルフォーマット及びプロトコルタイプがあります。下流詳細マッピングTLVがエコー応答で送信されると、このサブTLVを含まなければなりません。
Downstream Label
下流ラベル
A Downstream label is 24 bits, in the same format as an MPLS label minus the Time to Live (TTL) field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the Traffic Class (TC) field [RFC5462] is bits 20-22, and S is bit 23. The replying router SHOULD fill in the TC field and S bit; the LSR receiving the echo reply MAY choose to ignore these.
ダウンストリームラベルは、MPLSラベルと同じフォーマットで24ビットであるマイナス（TTL）フィールドを生存時間は、すなわち、ラベルのMSBitからビット0であり、最下位ビットはビット19であり、トラフィッククラス（TC）フィールド[ RFC5462]はビット20-22であり、Sは応答ルータがTCフィールドとSビットを記入すべきビット23です。エコー応答を受信LSRはこれらを無視することを選択するかもしれません。
Protocol
プロトコル
This specifies the label distribution protocol for the Downstream label.
これは、ダウンストリームラベルのラベル配布プロトコルを指定します。
A router MUST include the FEC stack change sub-TLV when the downstream node in the echo reply has a different FEC Stack than the FEC Stack received in the echo request. One or more FEC stack change sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The format is as below.
エコー応答における下流ノードがFECスタックとは異なるFECスタックがエコー要求で受信したときにルータがFECスタック切り替えサブTLVを含まなければなりません。一つ以上のFECスタック切り替えサブ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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FEC Stack Change Sub-TLV
図6：FECスタックの変更サブTLV
Operation Type
操作タイプ
The operation type specifies the action associated with the FEC stack change. The following operation types are defined:
操作タイプは、FECスタックの変更に関連するアクションを指定します。次の操作タイプが定義されています。
Type # Operation
------ ---------
1 Push
2 Pop
Address Type
アドレスタイプ
The Address Type indicates the remote peer's address type. The Address Type is set to one of the following values. The length of the peer address is determined based on the address type. The address type MAY be different from the address type included in the Downstream Detailed Mapping TLV. This can happen when the LSP goes over a tunnel of a different address family. The address type MAY be set to Unspecified if the peer address is either unavailable or the transit router does not wish to provide it for security or administrative reasons.
アドレスタイプは、リモートピアのアドレスタイプを示します。アドレスタイプは、次のいずれかの値に設定されています。ピアアドレスの長さは、アドレス・タイプに基づいて決定されます。アドレスタイプは、下流の詳細なマッピングTLVに含まれるアドレス・タイプと異なっていてもよいです。 LSPは異なるアドレスファミリのトンネル上になったときに発生することがあります。ピアアドレスが使用できないか、トランジットルータのどちらかである場合は、アドレスの種類は、セキュリティや管理上の理由のためにそれを提供したくない未指定に設定されるかもしれません。
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0 1 IPv4 4 2 IPv6 16
0未指定0 1 IPv4の4 2のIPv6 16
FEC TLV Length
FEC TLVの長さ
Length in bytes of the FEC TLV.
FEC TLVの長さ（バイト単位）。
Reserved
予約済み
This field is reserved for future use and MUST be set to zero.
このフィールドは、将来の使用のために予約され、ゼロに設定しなければなりません。
Remote Peer Address
リモートピアアドレス
The remote peer address specifies the remote peer that is the next-hop for the FEC being currently traced. For example, in the LDP over RSVP case in Figure 1, router B would respond back with the address of router D as the remote peer address for the LDP FEC being traced. This allows the ingress node to provide information regarding FEC peers. If the operation type is PUSH, the remote peer address is the address of the peer from which the FEC being pushed was learned. If the operation type is POP, the remote peer address MAY be set to Unspecified.
リモートピアのアドレスは、現在トレースされるFECのネクストホップであるリモートピアを指定します。 LDP FECのためのリモートピアアドレスがトレースされているように、例えば、図1のRSVPケース上LDPで、ルータBは、バックルータDのアドレスで応答します。これは、入口ノードがFECピアに関する情報を提供することができます。操作種別がPUSHである場合、リモートピアのアドレスがプッシュされてFECが学習されたピアのアドレスです。操作種別がPOPである場合、リモートピアアドレスが未指定に設定されるかもしれません。
For upstream-assigned labels [RFC5331], an operation type of POP will have a remote peer address (the upstream node that assigned the label) and this SHOULD be included in the FEC stack change sub-TLV. The remote peer address MAY be set to Unspecified if the address needs to be hidden.
上流割り当てられたラベル[RFC5331]のために、POPの動作タイプは、リモートピアアドレス（ラベルを割り当て上流ノード）を有し、これはFECスタック変化サブTLVに含まれるべきです。アドレスを非表示にする必要がある場合は、リモートピアアドレスは未指定に設定されるかもしれません。
FEC TLV
FEC TLV
The FEC TLV is present only when the FEC-tlv length field is non-zero. The FEC TLV specifies the FEC associated with the FEC stack change operation. This TLV MAY be included when the operation type is POP. It MUST be included when the operation type is PUSH. The FEC TLV contains exactly one FEC from the list of FECs specified in [RFC4379]. A Nil FEC MAY be associated with a PUSH operation if the responding router wishes to hide the details of the FEC being pushed.
FEC TLVはFEC-TLVの長さフィールドが非ゼロである場合にのみ存在します。 FEC TLVはFECスタックの変更操作に関連付けられているFECを指定します。操作タイプがPOPであるとき、このTLVが含まれるかもしれません。操作タイプがPUSHがあるときにそれを含まなければなりません。 FEC TLVは[RFC4379]で指定のFECのリストから、正確に1つのFECが含まれています。応答ルータが押されるFECの詳細を隠すことを望む場合ナシFECは、プッシュ操作に関連付けられてもよいです。
FEC stack change sub-TLV operation rules are as follows:
次のようにFECスタック変更サブTLV運用規則は次のとおりです。
a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT be followed by a FEC stack change sub-TLV containing a POP operation.
A。プッシュ動作を含むFECスタック切り替えサブTLVはFECスタック変更POP操作を含むサブTLVに続いてはいけません。
b. One or more POP operations MAY be followed by one or more PUSH operations.
B。一つ以上のPOP操作は、一つ以上のPUSH操作を行ってもよいです。
c. One FEC stack change sub-TLV MUST be included per FEC stack change. For example, if 2 labels are going to be pushed, then one FEC stack change sub-TLV MUST be included for each FEC.
C。一つのFECスタック切り替えサブTLVはFECスタック切り替え当たりに含まれるなければなりません。 2つのラベルは、次いで、プッシュしようとしている場合、例えば、1つのFECスタック切り替えサブTLVは、各FECのために含まれなければなりません。
d. A FEC splice operation (an operation where one FEC ends and another FEC starts, see Figure 7) MUST be performed by including a POP type FEC stack change sub-TLV followed by a PUSH type FEC stack change sub-TLV.
D。 FECスプライス動作（動作1つのFEC終了し、別のFEC開始、図7を参照）POP型FECスタック変化サブTLVを含めることによって実行されなければならないがPUSH型FECスタック変化サブTLVが続きます。
e. A Downstream detailed mapping TLV containing only one FEC stack change sub-TLV with Pop operation is equivalent to IS_EGRESS (Return Code 3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress router performing the MPLS traceroute MUST treat such a case as an IS_EGRESS for the outermost FEC.
電子。ポップ操作で一つだけFECスタック切り替えサブTLVを含む下流の詳細なマッピングTLVはFECスタックの最も外側のFECのためIS_EGRESS（戻りコード3、[RFC4379]）に相当します。 MPLSのtracerouteを実行入口ルータは、最も外側のFECのためIS_EGRESSようなケースを扱う必要があります。
This document deprecates the Downstream Mapping TLV. LSP ping procedures should now use the Downstream Detailed Mapping TLV. Detailed procedures regarding interoperability between the deprecated TLV and the new TLV are specified in Section 4.4.
この文書では、ダウンストリームマッピングTLVを非難します。 LSPピング手続きは今川下詳細なマッピングTLVを使用する必要があります。非推奨TLVと新しいTLV間の相互運用性に関する詳細な手順は、セクション4.4で指定されています。
This section describes the procedures to be followed by an LSP ingress node and LSP transit nodes when performing MPLS traceroute over MPLS tunnels.
このセクションでは、MPLSトンネル上のMPLS tracerouteを実行するときLSPの入口ノードおよびLSPトランジットノードによって従うべき手順を記載しています。
A transit node (Figure 1) knows when the FEC being traced is going to enter a tunnel at that node. Thus, it knows about the new outer FEC. All transit nodes that are the origination point of a new tunnel SHOULD add the FEC stack change sub-TLV (Section 3.3.1.3) to the Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node.
トランジットノード（図1）は、FECがトレースされているときに知っているノードにトンネルを入力しようとしています。したがって、それは新しい外FECについて知っています。新しいトンネルの起点であるすべてのトランジットノードは、エコー応答下流詳細マッピングTLV（図3）にFECスタック切り替えサブTLV（セクション3.3.1.3）を追加する必要があります。トランジットノードは、トランジットノードで発信され、新しいトンネル単位操作型PUSHのFECスタック切り替えサブTLVを追加する必要があります。
A transit node that sends a Downstream FEC stack change sub-TLV in the echo reply SHOULD fill the address of the remote peer; which is the peer of the current LSP being traced. If the transit node does not know the address of the remote peer, it MUST set the address type to Unspecified.
リモートピアのアドレスを記入すべきであるエコー応答下流FECスタック切り替えサブTLVを送信する中継ノード。これはトレースされている現在のLSPのピアです。トランジットノードは、リモートピアのアドレスを知らない場合には、未指定のアドレスタイプを設定しなければなりません。
The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label MUST be encoded as per Figure 5. The label value MUST be the value used to switch the data traffic. If the tunnel is a transparent pipe to the node, i.e. the data-plane trace will not expire in the middle of the new tunnel, then a FEC stack change sub-TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT contain a label corresponding to the hidden tunnel.
ラベルスタックサブTLVはFECが押されごとに1つの追加のラベルを含まなければなりません。ラベルは、ラベル値がデータトラフィックを切り替えるために使用される値でなければなりません図5に従って符号化されなければなりません。トンネルはノードへの透明パイプがある場合は、データ・プレーン・トレースは新しいトンネルの途中で期限切れになりません、すなわち、サブTLVを追加しないでくださいFECスタックの変更やラベルスタックサブTLVは含めるべきではありません隠されたトンネルに対応するラベル。
If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then it MAY not want to send details about the new tunnel FEC to the ingress. In such a case, the transit node SHOULD use the Nil FEC. The echo reply would then contain a FEC stack change sub-TLV with operation type PUSH and a Nil FEC. The value of the label in the Nil FEC MUST be set to zero. The remote peer address type MUST be set to Unspecified. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node. The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label value MUST be the value used to switch the data traffic.
トランジットノードは、エコー要求の進入からトンネルの本質を隠蔽しようとする場合、それは、入口に新しいトンネルFECについての詳細を送信したくない場合があります。このような場合、トランジットノードは、無記号FECを使用すべきです。エコー応答は、操作型PUSH及びナシFECとFECスタック変化サブTLVを含むであろう。無記号FEC内のラベルの値をゼロに設定しなければなりません。リモートピアのアドレス型が未指定に設定しなければなりません。トランジットノードは、トランジットノードで発信され、新しいトンネル単位操作型PUSHのFECスタック切り替えサブTLVを追加する必要があります。ラベルスタックサブTLVはFECが押されごとに1つの追加のラベルを含まなければなりません。ラベル値は、データトラフィックを切り替えるために使用される値でなければなりません。
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 7: Stitched LSPs
図7：ステッチのLSP
In the above figure, we have three separate LSP segments stitched at C and D. Node C SHOULD include two FEC stack change sub-TLVs. One with a POP operation for the LDP FEC and one with the PUSH operation for the BGP FEC. Similarly, node D SHOULD include two FEC stack change sub-TLVs, one with a POP operation for the BGP FEC and one with a PUSH operation for the RSVP FEC. Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to indicate change in FEC being traced.
上記の図では、我々は2つのFECスタック切り替えサブTLVを含むべきであるCおよびD、ノードCでステッチ3つの別々のLSPセグメントを有しています。 LDP FECのためのPOP動作とOneとBGP FECのためのPUSH動作と1。同様に、ノードDは、二つのFECスタック切り替えサブTLVの、BGP FEC用のPOP動作を有するものとRSVP FECのための押し操作のものを含むべきです。ノードCおよびDは、トレースされているFECの変化を示すために（セクション6.3）「をラベルはFEC変化に切り替え」に戻りコードを設定する必要があります。
If node C wishes to perform FEC hiding, it SHOULD respond back with two FEC stack change sub-TLVs, one POP followed by one PUSH. The POP operation MAY either exclude the FEC TLV (by setting the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change".
ノードCは、FEC隠蔽を実行したい場合、これは、2つのFECスタック切り替えサブTLVの、ワンプッシュ続い1つのPOPバック応じるべきです。 POP動作は、（0にFEC TLVの長さを設定することにより）FEC TLVを除外またはLDP FECを含有するFEC TLVを設定してもよいです。 PUSH操作は無記号FECを含むFEC TLVを持つべきである（SHOULD）。リターンコードは、「ラベルがFEC変化に切り替える」に設定する必要があります。
If node C performs FEC hiding and node D also performs FEC hiding, then node D MAY choose to not send any FEC stack change sub-TLVs in the echo reply since the number of labels has not changed (for the downstream of node D) and the FEC type also has not changed (Nil FEC). In such a case, node D MUST NOT set the Return Code to "Label switched with FEC change". If node D performs FEC hiding, then node F will respond as IS_EGRESS for the Nil FEC. The ingress (node A) will know that IS_EGRESS corresponds to the end-to-end LSP.
ノードCは、FEC隠れノードDもFEC隠蔽を実行行う場合、ノードDは、ラベルの数は、（ノードDの下流のために）変更されていないので、エコー応答に任意のFECスタック切り替えサブTLVを送信しないことを選択することができるとまた、変更されていないFECタイプ（無記号FEC）。そのような場合には、ノードDは、「ラベルがFEC変化に切り替え」に戻りコードを設定してはいけません。ノードDは、FEC隠蔽を実行する場合、ノードFは、無記号FECためIS_EGRESSとして応答します。入口（ノードA）はIS_EGRESSは、エンドツーエンドLSPに対応することを知っているであろう。
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDP
Figure 8: Hierarchical LSPs
図8：階層のLSP
In the above figure, we have an end-to-end LDP LSP between nodes A and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself goes over another RSVP LSP RSVP-A. When node A initiates a traceroute for the end-to-end LDP LSP, then following sequence of FEC stack change sub-TLVs will be performed
上記の図では、ノードAおよびFザLDP LSP間のエンドツーエンドLDP LSPを有するLSP RSVPのRSVP-Bを乗り越えます。 LSPのRSVP-B自体は別のRSVP LSPのRSVP-Aの上に行きます。ノードAは、FECスタック切り替えサブのTLVの次のシーケンスが実行され、エンドツーエンドLDP LSPのためにトレースルートを開始したとき
Node B:
ので Ｂ：
Respond with two FEC stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
PUSH RSVP-B、プッシュRSVP-A 2つのFECスタック切り替えサブのTLVで応答します。
Node D:
ノードD：
Respond with Return Code 3 when RSVP-A is the top of FEC stack. When the echo request contains RSVP-B as top of stack, respond with Downstream information for node E and an appropriate Return Code.
RSVP-Aは、FECスタックの最上位であるとき、戻りコード3で応答します。エコー要求は、スタックの最上位としてRSVP-Bが含まれている場合は、ノードEのためのダウンストリーム情報と適切なリターンコードで応答します。
If node B is performing tunnel hiding, then:
ノードBは、次に、トンネルの隠蔽を行っている場合：
Node B:
ので Ｂ：
Respond with two FEC stack change sub-TLVs: PUSH Nil FEC, PUSH Nil FEC.
2つのFECスタックの変更サブのTLVで応答：なしFECを押し、無記号FECを押してください。
Node D:
ノードD：
If D determines that the Nil FEC corresponds to RSVP-A, which terminates at D, then it SHOULD respond with Return Code 3. D can also respond with FEC stack change sub-TLV: POP (since D knows that number of labels towards next-hop is decreasing). Both responses would be valid.
Dは、次へのラベルの数を知っているので、POP（：Dは無記号FECはDで終了する、-AをRSVPに対応することを決定した場合、それは3 Dはまた、FECスタック切り替えサブTLVで応答することができ戻りコードで応答する必要があります-hop）が減少しています。どちらの応答が有効になります。
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDP
Figure 9: Stitched Hierarchical LSPs
図9：ステッチ階層のLSP
In the above case, node D will send three FEC stack change sub-TLVs. One POP (for the BGP FEC) followed by two PUSHes (one for LDP and one for RSVP). Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to indicate change in FEC being traced.
上記の場合、ノードDは、三のFECスタック切り替えサブTLVを送信します。 （BGP FEC用）一つPOPは、二つのプッシュ（LDP用とRSVPのための1つ）が続きます。ノードCおよびDは、トレースされているFECの変化を示すために（セクション6.3）「をラベルはFEC変化に切り替え」に戻りコードを設定する必要があります。
Section 4.4 of [RFC4379] specifies Target FEC stack validation procedures. This document enhances the FEC validation procedures as follows. If the outermost FEC of the target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely. This is to support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
[RFC4379]のセクション4.4はターゲットFECスタックの検証手順を指定します。次のようにこの文書では、FECの検証手順を強化します。ターゲットFECスタックの最FECがnil FECの場合、ノードは完全にターゲットFEC検証をスキップしなければなりません。これは、外側の隠されたFECがnil FECすることができるFEC隠しを、サポートすることです。
Section 4.4 of [RFC4379] specifies Target FEC stack validation procedures. This document enhances the FEC validation procedures as follows. If the outermost FEC of the Target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely. This is to support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
[RFC4379]のセクション4.4はターゲットFECスタックの検証手順を指定します。次のようにこの文書では、FECの検証手順を強化します。ターゲットFECスタックの最FECがnil FECの場合、ノードは完全にターゲットFEC検証をスキップしなければなりません。これは、外側の隠されたFECがnil FECすることができるFEC隠しを、サポートすることです。
It is the responsibility of an ingress node to understand tunnel within tunnel semantics and LSP stitching semantics when performing a MPLS traceroute. This section describes the ingress node procedure based on the kind of reply an ingress node receives from a transit node.
MPLS tracerouteを実行するときにトンネルセマンティクスとLSPステッチセマンティクス内のトンネルを理解する入口ノードの責任です。このセクションでは、入口ノードは、トランジットノードから受信する応答の種類に基づいて、入口ノードの手順が記載されています。
Downstream Detailed Mapping TLV should be processed in the same way as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379]. This section describes the procedures for processing the new elements introduced in this document.
下流詳細マッピングTLVは[RFC4379]のセクション4.4で定義され、下流マッピングTLVと同じ方法で処理されるべきです。このセクションでは、この文書に導入された新しい要素を処理するための手順を説明します。
This would be the default behavior as described in [RFC4379]. The ingress node MUST perform MPLS echo reply processing as per the procedures in [RFC4379].
[RFC4379]で説明したように、これがデフォルトの動作になります。入口ノードは、[RFC4379]の手順に従ってMPLSエコー応答処理を実行しなければなりません。
If one or more FEC stack change sub-TLVs (Section 3.3.1.3) are received in the MPLS echo reply, the ingress node SHOULD process them and perform some validation.
一つ以上のFECスタック切り替えサブのTLV（セクション3.3.1.3）は、MPLSエコー応答で受信される場合、入口ノードは、それらを処理し、いくつかの検証を実行する必要があります。
The FEC stack changes are associated with a downstream neighbor and along a particular path of the LSP. Consequently, the ingress will need to maintain a FEC stack per path being traced (in case of multipath). All changes to the FEC stack resulting from the processing of FEC stack change sub-TLV(s) should be applied only for the path along a given downstream neighbor. The following algorithm should be followed for processing FEC stack change sub-TLVs.
FECスタックの変更は、下流ネイバーとし、LSPの特定の経路に沿って関連付けられています。その結果、入口は、（マルチパスの場合）トレースされる経路ごとFECスタックを維持する必要があります。 FECスタック変化サブTLV（S）の処理に起因するFECスタックに対するすべての変更は、所定のダウンストリームネイバーに沿った経路に適用されるべきです。以下のアルゴリズムは、FECスタック切り替えサブTLVを処理するために従うべきです。
push_seen = FALSE fec_stack_depth = current-depth-of-fec-stack-being-traced saved_fec_stack = current_fec_stack
push_seen = FALSE fec_stack_depth =電流深度の-FECスタックビーイング・トレースsaved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
一方、（サブTLV = get_next_sub_tlv（downstream_detailed_map_tlv））
if (sub-tlv == NULL) break
もし（サブTLV == NULL）休憩
if (sub-tlv.type == FEC-Stack-Change) {
IF（サブtlv.type == FECスタック-変更）{
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced fec_stack_depth--; }
fec_stack_depth--トレースされているFECスタックからFECをポップ。 }
if (sub-tlv.operation == PUSH) { push_seen = 1 Push FEC on FEC stack being traced fec_stack_depth++; } } }
IF（サブtlv.operation == PUSH）{push_seen = 1 ++ fec_stack_depthをトレースされてFECスタックにFECを押します。 }}}
if (fec_stack_depth == 0) { Drop the echo reply current_fec_stack = saved_fec_stack return }
（fec_stack_depth == 0）{エコー応答current_fec_stack = saved_fec_stackリターンドロップ}場合
Figure 10: FEC Stack Change Sub-TLV Processing Guideline
図10：FECスタックの変更サブTLV処理ガイドライン
The next MPLS echo request along the same path should use the modified FEC stack obtained after processing the FEC stack change sub-TLVs. A non-Nil FEC guarantees that the next echo request along the same path will have the Downstream Detailed Mapping TLV validated for IP address, Interface address, and label stack mismatches.
同じ経路に沿って次のMPLSエコー要求は、FECスタック切り替えサブTLVを処理した後に得られる変性FECスタックを使用する必要があります。非無記号FEC同じパスに沿って次のエコー要求は、IPアドレス、インターフェイスアドレス、およびラベルスタックの不一致を検証ダウンストリームの詳細なマッピングTLVをもつことが保証されます。
If the top of the FEC stack is a Nil FEC and the MPLS echo reply does not contain any FEC stack change sub-TLVs, then it does not necessarily mean that the LSP has not started traversing a different tunnel. It could be that the LSP associated with the Nil FEC terminated at a transit node and at the same time a new LSP started at the same transit node. The Nil FEC would now be associated with the new LSP (and the ingress has no way of knowing this). Thus, it is not possible to build an accurate hierarchical LSP topology if a traceroute contains Nil FECs.
FECスタックのトップがゼロFEC及びMPLS任意FECスタック切り替えサブTLVを含んでいないエコー応答である場合、それは必ずしもLSPが異なるトンネルを横断開始していないことを意味するものではありません。これは、新しいLSPトランジットノードで、同じ時間で終了ナシFECに関連したLSPは、同じトランジットノードで開始している可能性があります。無記号FECは、新しいLSPに関連するであろう（と進入はこれを知る方法はありません）。したがって、トレースルートがnilのFECが含まれている場合は、正確な階層的なLSPトポロジを構築することはできません。
The procedures above allow the addition of new FECs to the original FEC being traced. Consequently, a reply from a downstream node with Return Code 3 (IS_EGRESS) may not necessarily be for the FEC being traced. It could be for one of the new FECs that was added. On receipt of an IS_EGRESS reply, the LSP ingress should check if the depth of Target FEC sent to the node that just responded, was the same as the depth of the FEC that was being traced. If it was not, then it should pop an entry from the Target FEC stack and resend the request with the same TTL (as previously sent). The process of popping a FEC is to be repeated until either the LSP ingress receives a non-IS_EGRESS reply or until all the additional FECs added to the FEC stack have already been popped. Using an IS_EGRESS reply, an ingress can build a map of the hierarchical LSP structure traversed by a given FEC.
上記の手順は、トレースされて、元のFECへの新規のFECの追加を可能にします。したがって、戻りコード3（IS_EGRESS）と下流ノードからの応答は、必ずしも、FECがトレースされるためではないかもしれません。これは、追加された新しいのFECのいずれかの可能性があります。 IS_EGRESS応答を受信すると、ターゲットFECの深さはちょうど応答ノードに送信される場合にLSPの入口を確認する必要があり、トレースされたFECの深さと同じでした。そうでない場合、それはターゲットFECスタックからエントリをポップし、（以前に送信されたように）同じTTLで要求を再送信すべきです。 LSPの入口のいずれかが非IS_EGRESS応答を受信するか、すべての追加のFECは、FECスタックに追加されるまで、既にポップされるまで、FECをポップの処理が繰り返されます。 IS_EGRESS応答を使用して、入力が与えられたFECが横断階層LSP構造のマップを構築することができます。
When the MPLS echo reply Return Code is "Label switched with FEC change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC stack as per the FEC stack change sub-TLVs contained in the downstream detailed mapping TLV. A transit node can use this Return Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, there could be multiple paths and Downstream Detailed Mapping TLVs with different Return Codes (Section 3.2.1). The ingress node should build the topology based on the Return Code per ECMP path/P2MP branch.
MPLSエコー応答戻りコード（セクション3.2.2）「ラベルFEC変化に切り替える」であるとき、入口ノードはFECスタック変化下流詳細なマッピングTLVに含まれるサブTLVの通りFECスタックを操作すべきです。トランジットノードは、ステッチのLSPのために、階層のLSPのために、このリターンコードを使用することができます。 ECMPまたはP2MPの場合には、異なる戻りコード（セクション3.2.1）と複数のパスと下流詳細なマッピングのTLVが存在し得ます。入口ノードは、ECMPパス/ P2MP分岐あたりの戻りコードに基づいてトポロジを構築する必要があります。
The Downstream Mapping TLV has been deprecated. Applications should now use the Downstream Detailed Mapping TLV. The following procedures SHOULD be used for backward compatibility with routers that do not support the Downstream Detailed Mapping TLV.
ダウンストリームマッピングTLVは廃止されました。アプリケーションは今川下詳細なマッピングTLVを使用する必要があります。次の手順では、ダウンストリームの詳細なマッピングTLVをサポートしていないルータとの下位互換性のために使用されるべきです。
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV MUST never be sent together in the same MPLS echo request or in the same MPLS echo reply.
ダウンストリームマッピングTLV及び下流詳細マッピングTLV oを同一のMPLSエコー要求又は同一のMPLSエコー応答内で一緒に送信されてはなりません。
o If the echo request contains a Downstream Detailed Mapping TLV and the corresponding echo reply contains a Return Code 2 ("One or more of the TLVs was not understood"), then the sender of the echo request MAY resend the echo request with the Downstream Mapping TLV (instead of the Downstream Detailed Mapping TLV). In cases where a detailed reply is needed, the sender can choose to ignore the router that does not support the Downstream Detailed Mapping TLV.
エコー要求が下流詳細マッピングTLVが含まれており、対応するエコー応答が戻りコード2（「のTLVの一つ以上が理解されませんでした」）が含まれている場合は、O、次いで、エコー要求の送信者が下流でエコー要求を再送MAYマッピングTLV（代わりの下流詳細マッピングTLV）。詳細な返信が必要な場合には、送信者は、川下の詳細なマッピングTLVをサポートしていないルータを無視することを選択することができます。
o If the echo request contains a Downstream Mapping TLV, then a Downstream Detailed Mapping TLV MUST NOT be sent in the echo reply. This is to handle the case that the sender of the echo request does not support the new TLV. The echo reply MAY contain Downstream Mapping TLV(s).
エコー要求は、ダウンストリームマッピングTLVが含まれている場合は、O、そして川下詳細なマッピングTLVは、エコー応答に送ってはいけません。これはエコー要求の送信者が新しいTLVをサポートしていないケースを処理することです。エコー応答は、ダウンストリームマッピングTLV（複数可）を含有してもよいです。
o If echo request forwarding is in use (such that the echo request is processed at an intermediate LSR and then forwarded on), then the intermediate router is responsible for making sure that the TLVs being used among the ingress, intermediate and destination are consistent. The intermediate router MUST NOT forward an echo request or an echo reply containing a Downstream Detailed Mapping TLV if it itself does not support that TLV.
エコー要求の転送を使用している場合はO（エコー要求は中間LSRで処理した後に転送されるように）、次いで、中間ルータはのTLVが入口の間使用されていることを確認する責任がある、中間及び宛先が一致しています。中間ルータは、エコー要求またはそれ自体がそのTLVをサポートしていない場合は川下の詳細なマッピングTLVを含むエコー応答を転送してはなりません。
1. If a network operator wants to prevent tracing inside a tunnel, one can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel). By doing this, MPLS traceroute packets will not expire in the outer tunnel and the outer tunnel will not get traced.
1.ネットワークオペレータがトンネル内トレースを防止したい場合には、一方が（外側のトンネルの開始時に）外側トンネルにMPLS TTLを伝播しないことにより、外側のMPLSトンネルを隠す、すなわち、パイプモデル[RFC3443]を使用することができ。これにより、MPLSのトレースルートパケットは、外側トンネルに期限切れになりませんし、外側のトンネルはトレースされません。
2. If one doesn't wish to expose the details of the new outer LSP, then the Nil FEC can be used to hide those details. Using the Nil FEC ensures that the trace progresses without false negatives and all transit nodes (of the new outer tunnel) perform some minimal validations on the received MPLS echo requests.
2. 1の新外側LSPの詳細を公開したくない場合は、無記号FECは、それらの詳細を隠すために使用することができます。無記号FECを使用すると、受信したMPLSエコー要求である最小検証を実行トレースは偽陰性と（新しいアウタートンネルの）すべてのトランジットノードなしで進行することを確実にします。
Other security considerations, as discussed in [RFC4379], are also applicable to this document.
その他のセキュリティの考慮事項は、[RFC4379]で説明したように、また、この文書に適用されます。
IANA has assigned a TLV type value to the following TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANAから、次のTLVへのTLVタイプの値を割り当てられた、「TLVのサブTLVの」サブレジストリレジストリ「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルはパス（LSPの）Pingのパラメータをスイッチ」。
Downstream Detailed Mapping TLV (see Section 3.3): 20.
下流詳細マッピングTLV（セクション3.3を参照）：20。
IANA has registered the Sub-Type field of Downstream Detailed Mapping TLV. The valid range for this is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC3692]; assignments in the range 16384-31743 and 49162-64511 are made via Specification Required [RFC4379]; values in the range 31744- 32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Enterprise Code, in network octet order. The rest of the Value field is private to the vendor.
IANAは、ダウンストリームの詳細なマッピングTLVのサブタイプのフィールドが登録されています。このため、有効な範囲は0〜65535です。 [RFC3692]で定義されるように範囲0から16383と32768から49161で割り当ては標準アクションを介して行われます。範囲16384から31743と49162から64511に割り当てが必要な仕様[RFC4379]を介して行われます。範囲31744- 32767および64512から65535の値はベンダー私的使用のためであり、割り当てられてはなりません。サブTLVは、ベンダー私的使用のための範囲内に収まるタイプを持っている場合、長さは少なくとも4でなければならない、と最初の4つのオクテットは、ネットワークオクテット順に、そのベンダーのSMIエンタープライズコードである必要があります。 Valueフィールドの残りの部分は、ベンダーにプライベートです。
IANA has assigned the following sub-TLV types (see Section 3.3.1):
IANAは以下のサブTLVタイプ（セクション3.3.1を参照）が割り当てられています：
Multipath data: 1
マルチパスのデータ：1
Label stack: 2
ラベルスタック：2
FEC stack change: 3
FECスタックの変更：3
IANA has assigned new Return Code values from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry, as follows using a Standards Action value.
IANAは標準アクション値を使用して、以下のように、サブレジストリ「リターンコード」、レジストリ「ラベルは、（のLSP）Pingのパラメータをパススイッチドマルチプロトコルラベルスイッチング（MPLS）」から、新たな戻りコード値を割り当てました。
Value Meaning
----- -------
14 See DDM TLV for Return Code and Return Subcode
15 Label switched with FEC change
The authors would like to thank Yakov Rekhter and Adrian Farrel for their suggestions on the document.
作者は、ドキュメント上の彼らの提案のためのヤコフ・レックターとエードリアンファレルに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwalさん、P.とB. Akyol、 "（MPLS）ネットワークのマルチプロトコルラベルスイッチングにおける生存時間（TTL）処理"、RFC 3443、2003年1月。
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]安川、S.、RFC 4461、2006年4月「ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）」。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、JP。、およびA.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]アガルワル、R.、Rekhter、Y.、およびE.ローゼン、 "MPLS上流ラベルの割り当てとコンテキスト固有のラベルスペース"、RFC 5331、2008年8月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
Authors' Addresses
著者のアドレス
Nitin Bahadur Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
ニティン・バハドゥール・ジュニパーネットワークス株式会社1194 N.マチルダアベニューサニーベール、CA 94089米国
Phone: +1 408 745 2000 EMail: nitinb@juniper.net URI: www.juniper.net
電話：+1 408 745 2000 Eメール：nitinb@juniper.net URI：www.juniper.net
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニューサニーベール、CA 94089米国
Phone: +1 408 745 2000 EMail: kireeti@juniper.net URI: www.juniper.net
電話：+1 408 745 2000 Eメール：kireeti@juniper.net URI：www.juniper.net
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 US
ジョージツバメシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719米国
EMail: swallow@cisco.com URI: www.cisco.com
電子メール：swallow@cisco.com URI：www.cisco.com