[要約] RFC 6424は、MPLSトンネル上でラベルスイッチパスピン（LSP Ping）を実行するためのメカニズムを提供しています。目的は、MPLSネットワーク内のラベルスイッチパスの可用性とパフォーマンスを監視することです。
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
MPLSトンネル上でラベルスイッチ付きパス（LSP ping）を実行するためのメカニズム
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トンネル上でLSP Ping（RFC 4379で指定）を実行する方法と、ステッチされたMPLSラベルスイッチ付きパス（LSP）のトレーサーを実行する方法について説明します。RFC 4379で概説されている手法は、他のMPLSトンネルを越えたLSPまたはステッチ付きLSPに対して、Traceroute転送等価クラス（FEC）検証とパス発見を実行するには不十分です。このドキュメントは、このドキュメントで概説されている他の手順とともに、そのようなLSPをトレースするために使用できる新しいTLVを支持して、下流マッピングTLV（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/rfc6424.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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ライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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トンネルを介してTracerouteを実行するLSP ping（[RFC4379]で指定）を実行する方法について説明しています。[RFC4379]の手法は、等価クラス（FEC）検証と等しいコストマルチパス（ECMP）パス発見を含むトレーサーアウトメカニズムの概要を説明します。これらのメカニズムは不十分であり、FECがトレースされているFECが1つ以上のMPLSトンネルを通過し、ラベルスイッチドパス（LSP）ステッチ[RFC5150]が使用されている場合、詳細を提供しません。このドキュメントは、下流のマッピングTLV [RFC4379]を非難し、代わりにより拡張可能で詳細情報の取得を可能にする新しいTLVを導入します。[RFC4379]の既存の定義とともに新しいTLV形式を使用して、このドキュメントでは、Traceroute要求が適切な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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
An LSP ping traceroute may cross multiple MPLS tunnels en route to the destination. Let us consider a simple case.
LSP Ping Tracerouteは、目的地に向かう途中で複数の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
Router AからTracerouteが開始されると、Router BはMPLSエコー応答のノードCの下流マッピング情報を返します。次のMPLSエコー要求は、LDP FECでルーターCに到達します。ノードCは純粋なRSVPノードであり、LDPを実行しません。ノードCは、2つのラベルでMPLSエコー要求を受け取りますが、ターゲットFECスタックにはFECが1つだけです。その結果、ノード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エコー要求には、ノードCがFEC検証を実行して誤った誤ったエコーリクエストをキャッチできるようにするのに十分な情報を含める必要があります。
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トンネルになります）。トンネルのFEC検証の問題は、新しいトンネルの開始に関して、輸送ルーター（上記の例のルーターB）が侵入にいくつかの情報を提供する場合に解決できます。
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には、2つ以上の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.
イングレス（a）エンドツーエンドのステッチLSP aをトレースすることを検討します。MPLSエコー要求がルーターCに到達すると、ルーターCでFECスタックの変更が発生します。現在のLSP Ping [RFC4379]メカニズムを使用して、この情報をAに伝える方法はありません。、ルーターDは、Aが追跡しようとしているLDP FECについて何も知りません。
Thus, the procedures defined in [RFC4379] do not make it possible for the ingress node to:
したがって、[RFC4379]で定義されている手順は、イングレスノードが次のことを可能にしません。
1. Know that tunneling has occurred.
1. トンネリングが発生したことを知ってください。
2. Trace the path of the tunnel.
2. トンネルの経路を追跡します。
3. Trace the path of stitched LSPs.
3. ステッチされたLSPの経路を追跡します。
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
多くの場合、MPLSエコー応答で追加データを関連付ける必要があります。ほとんどの場合、追加のデータは、ストリーム通信ごとに関連付ける必要があります。現在、MPLSエコーの応答には、ダウンストリームあたり1つのダウンストリームマッピングTLV（DSMAP）が含まれています
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:
近所の人。ただし、DSMAP形式は拡張できません。したがって、より多くの情報を下流の隣人に関連付けることはできません。このドキュメントでは、DSMAPの新しい拡張可能な形式を定義し、新しい形式を使用してトンネル化されたLSP ping問題を解決するためのメカニズムを提供します。要約すると、このドキュメントは次の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 ダウンストリームFECスタックの追加Sub-TLVをDDMAPに変更します。
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.
新しい返品コードは、「戻りコードとリターンサブコードについてはDDM TLVを参照してください」（セクション6.3）と定義されています。この返品コードは、メッセージヘッダーでのみ使用する必要があり、MPLSエコー応答メッセージでのみ設定する必要があります。MPLSエコーリクエストメッセージで戻りコードが設定されている場合、無視する必要があります。この戻りコードが設定されている場合、下流の詳細マッピングTLVには適切な返品コードとリターンサブコードが必要です。この返品コードは、特定のノードに複数のダウンストリーム（ポイントトゥマルチポイント（P2MP）または等しいコストマルチパス（ECMP）など）がある場合に使用する必要があり、ノードは各下流のリターンコード/返信サブコードを返す必要があります。。この返品コードは、特定のノードに1つの下流のみがある場合でも使用できます。
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）でTracerouteが実行されている場合、ステッチポイントは、トレースを実行するノードに対するステッチアクションを示す必要があります。これは、戻りコードを「FEC変更で切り替えたラベル」に設定することによって行われます（セクション6.3）。ノードがFEC隠蔽を実行している場合、「FEC変更で切り替えられたラベル」以外に、戻りコードを値（[RFC4379]で指定）に設定することを選択できます。FECスタックSub-TLV（セクション3.3.1.3）が下流の詳細なマッピングTLVに存在しない場合、「FEC変更で切り替えられたラベル」のリターンコードを使用しないでください。この新しい返品コードは、階層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です。Echoリクエストには、下流の詳細なマッピングオブジェクトが1つだけ表示される場合があります。下流の詳細なマッピングオブジェクトの存在は、下流の詳細マッピングオブジェクトを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フラグフィールドは、さまざまなフラグの少しベクトルです。
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パラメーター「レジストリ」、「リターンコード」サブレジストリで指定された値の1つに設定できます。
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に戻るコードフィールドの非ゼロ値を設定した場合、受信者はecho Replyヘッダーに戻りコードフィールドを設定して、「戻りコードのDDM TLVを参照してサブコードを返す」（セクション」を設定する必要があります。6.3）。これの例外は、受信機がバッドノード[RFC4461]であり、3のリターンコードを持つ出口とトランジットノードの両方として応答している場合です（ "Replyingルーターは、Stack-Depth <RSC>のFECの出口です」）エコー応答ヘッダー。
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.
Echo Replyメッセージの返信コードが「戻りコードについてDDM TLVを参照してサブコードを返す」（セクション6.3）または「Replying RouterがStack-Depth <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パラメーター「レジストリ」、「リターンコード」サブレジストリで指定された値の1つに設定できます。このフィールドには、スタックの深さを指定するコードのスタックが濃縮されています。他のすべてのコードでは、返品サブコードをゼロに設定する必要があります。
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.
Echo Replyメッセージの返信コードが「戻りコードについてDDM TLVを参照してサブコードを返す」（セクション6.3）または「Replying RouterがStack-Depth <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：MultiPath Sub-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:
MultiPath Data Sub-TLVには、MultiPath情報が含まれています。サブTLVフィールドとその使用法は、[RFC4379]で定義されています。フィールドの簡単な要約は次のとおりです。
Multipath Type
マルチパスタイプ
The type of the encoding for the Multipath Information.
マルチパス情報のエンコーディングのタイプ。
Multipath Length
マルチパス長
The length in octets of the Multipath Information.
マルチパス情報のオクテットの長さ。
MBZ
MBZ
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：ラベルスタックSub-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.
ラベルスタックSub-TLVには、このルーターがこのインターフェイスを介してパケットを転送している場合に表示されるレーベルスタック内のラベルのセットが含まれています。暗黙のヌルラベルは明示的に含まれています。Sub-TLVに存在するラベル/プロトコルペアの数は、Sub-TLVデータの長さに基づいて決定されます。ラベル形式とプロトコルタイプは、[RFC4379]で定義されています。下流の詳細マッピングTLVがEcho Replyで送信される場合、このサブ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.
ダウンストリームラベルは24ビットで、MPLSラベルからライブ（TTL）フィールドを差し引いたものと同じ形式で、つまりラベルのMSBITはビット0です。LSBITはビット19、トラフィッククラス（TC）フィールド[RFC5462]はビット20-22で、Sはビット23です。応答ルーターは、TCフィールドとSビットを埋める必要があります。エコー応答を受信する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.
ルーターには、Echo Replyの下流ノードがEcho要求で受信したFECスタックとは異なるFECスタックを持っている場合、FECスタック変更Sub-TLVを含める必要があります。下流の詳細マッピングTLVには、1つ以上のFECスタック変更サブ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
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の次のホップであるリモートピアを指定します。たとえば、図1のRSVPケースを介したLDPでは、ルーターBは、トレースされているLDP FECのリモートピアアドレスとして、ルーターDのアドレスで応答します。これにより、IngressノードはFECピアに関する情報を提供できます。操作タイプがプッシュされている場合、リモートピアアドレスは、プッシュされるFECが学習されたピアのアドレスです。操作タイプがポップの場合、リモートピアアドレスを不特定に設定することができます。
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を指定します。このTLVは、操作タイプがPOPの場合に含まれる場合があります。操作タイプがプッシュされている場合は、含める必要があります。FEC TLVには、[RFC4379]で指定されたFECのリストからちょうど1つのFECが含まれています。NIL 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スタック変更SUB-TLVの後に、POP操作を含むFECスタック変更SUB-TLVを使用してはなりません。
b. One or more POP operations MAY be followed by one or more PUSH operations.
b. 1つ以上のポップ操作に続いて、1つ以上のプッシュ操作が続く場合があります。
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スタックの変更ごとに、1つのFECスタック変更SUB-TLVを含める必要があります。たとえば、2つのラベルがプッシュされる場合、FECごとにFECスタック変更SUB-TLVを含める必要があります。
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を参照）を実行する必要があります。FECスタック変更Sub-TLVを含めて、プッシュタイプFECスタック変更Sub-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.
e. POP操作を備えたFECスタック変更サブTLVのみを含む下流の詳細なマッピングTLVは、FECスタックの最も外側のFECのIS_EGRESS（戻りコード3、[RFC4379]）に相当します。MPLS Tracerouteを実行するIngressルーターは、そのようなケースを最も外側の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 Ping手順では、下流の詳細マッピング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トレーサーを実行する際の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について知っています。新しいトンネルのオリジネーションポイントであるすべてのトランジットノードは、echo応答の下流の詳細なマッピングTLV（図3）にFECスタック変更サブTLV（セクション3.3.1.3）を追加する必要があります。トランジットノードは、新しいトンネルごとにトランジットノードで発信される1つの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.
ラベルスタックSub-TLVには、押し出されているFECごとに1つの追加ラベルを含める必要があります。ラベルは、図5に従ってエンコードする必要があります。ラベル値は、データトラフィックの切り替えに使用される値でなければなりません。トンネルがノードへの透明なパイプ、つまりデータプレーントレースが新しいトンネルの中央で期限切れにならない場合、FECスタック変更Sub-TLVを追加せず、ラベルスタックSub-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の詳細をイングレスに送信したくない場合があります。そのような場合、トランジットノードはNIL FECを使用する必要があります。エコー応答には、操作タイププッシュとnil FECを備えたFECスタック変更サブTLVが含まれます。NIL FECのラベルの値は、ゼロに設定する必要があります。リモートピアアドレスタイプは、特定されていないように設定する必要があります。トランジットノードは、新しいトンネルごとにトランジットノードで発信される1つのFECスタック変更型プッシュのサブTLVを追加する必要があります。ラベルスタックSub-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.
上記の図では、Cに縫い付けられた3つの別々のLSPセグメントがあり、DノードCには2つのFECスタック変更サブTLVを含める必要があります。LDP FECのポップ操作があり、1つはBGP FECのプッシュ操作を備えています。同様に、ノードDには2つのFECスタック変更サブTLVを含める必要があります。1つはBGP FECのポップ操作、もう1つはRSVP FECのプッシュ操作を備えています。ノードCとDは、returnコードを「FEC変更で切り替えたラベル」に設定する必要があります（セクション6.3）。
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
Node CがFEC隠蔽を実行したい場合、2つのFECスタック変更サブTLVで応答し、1つのPOPに続いて1つのプッシュが続きます。POP操作は、FEC TLVを除外し（FEC TLVの長さを0に設定することにより）、FEC TLVをLDP FECを含むように設定します。プッシュ
operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change".
操作には、NIL FECを含むFEC TLVが必要です。返品コードは、「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タイプも変更されていません（NIL FEC）。そのような場合、ノードDは、「FEC変更で切り替えられたラベル」に戻りコードを設定してはなりません。Node DがFEC HIDINGを実行すると、NIL FECのIS_EGRESSとしてノードFが応答します。Ingress（ノード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があります。LDPLSPはRSVP LSP RSVP-Bを超えています。LSP RSVP-B自体は、別のRSVP LSP RSVP-Aを超えています。ノードAがエンドツーエンドLDP LSPのトレーサーアウトを開始すると、FECスタック変更のシーケンスサブTLVが実行されます
Node B:
ノードB：
Respond with two FEC stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
2つのFECスタック変更サブTLVで応答します。RSVP-Bを押し、RSVP-Aをプッシュします。
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:
ノードB：
Respond with two FEC stack change sub-TLVs: PUSH Nil FEC, PUSH Nil FEC.
2つのFECスタック変更サブTLVで応答します。
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がNIL FECがDで終了するRSVP-Aに対応すると判断した場合、return Code 3で応答する必要があります。-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は3つのFECスタック変更サブTLVを送信します。1つのPOP（BGP FEC用）に続いて2つのプッシュ（1つはLDP用、もう1つはRSVP用）が続きます。ノードCとDは、returnコードを「FEC変更で切り替えたラベル」に設定する必要があります（セクション6.3）。
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]で説明されているデフォルトの動作です。Ingressノードは、[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.
MPLSエコー応答で1つ以上のFECスタック変更サブTLV（セクション3.3.1.3）が受信された場合、イングレスノードはそれらを処理して検証を実行する必要があります。
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スタック変更Sub-TLVの処理に起因する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 = current-depth-of-of-of-of-of-stack-being-traced saved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
while（sub-tlv = get_next_sub_tlv（downstream_detailed_map_tlv））
if (sub-tlv == NULL) break
if（sub-tlv == null）break
if (sub-tlv.type == FEC-Stack-Change) {
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スタックからのPOP FEC-;}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
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スタックを使用する必要があります。NIL以外の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スタックの上部がNIL FECであり、MPLSエコー応答にFECスタック変更サブTLVが含まれていない場合、LSPが別のトンネルを通過し始めていないことを必ずしも意味しません。NIL FECに関連付けられたLSPは、トランジットノードで終了し、同時に同じトランジットノードで新しいLSPが開始された可能性があります。NIL FECは、新しいLSPに関連付けられています（そして、入り込みにはこれを知る方法がありません）。したがって、TracerouteにNIL FECが含まれている場合、正確な階層LSPトポロジを構築することはできません。
4.3.2. Modifications to Handling a Return Code 3 Reply.
4.3.2. 返信コード3の処理の変更。返信。
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の1つである可能性があります。IS_EGressの応答を受け取ったとき、LSP Ingressは、応答したノードに送信されたターゲットFECの深さが、追跡されていたFECの深さと同じであるかどうかを確認する必要があります。そうでない場合は、ターゲットFECスタックからエントリをポップし、同じTTL（以前に送信された）でリクエストを再送信する必要があります。FECをポップするプロセスは、LSP Ingressが非IS_EGRESS応答を受信するか、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 Echo Reply Return Codeが「FEC変更でラベルを切り替えた」（セクション3.2.2）の場合、Ingressノードは、下流の詳細マッピングTLVに含まれるFECスタック変更サブTLVに従ってFECスタックを操作する必要があります。トランジットノードは、ステッチされたLSPおよび階層LSPにこの返品コードを使用できます。ECMPまたはP2MPの場合、異なるリターンコードを持つ複数のパスと下流の詳細なマッピングTLVが存在する可能性があります（セクション3.2.1）。Ingressノードは、ECMP Path/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.
o ダウンストリームマッピングTLVと下流の詳細マッピングTLVは、同じ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.
o エコーリクエストに下流の詳細マッピングTLVが含まれ、対応するエコー返信に戻りコード2（「1つ以上のTLVが理解されていなかった」）が含まれている場合、エコーリクエストの送信者は、下流マッピングでエコー要求を再度再送信する場合があります。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).
o エコー要求にダウンストリームマッピングTLVが含まれている場合、下流の詳細マッピングTLVをEcho返信に送信してはなりません。これは、エコー要求の送信者が新しい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. ネットワークオペレーターがトンネル内でのトレースを防ぎたい場合、パイプモデル[RFC3443]を使用できます。つまり、MPLS TTLを外側トンネルに伝播しないことで外側のMPLSトンネルを非表示にします（外側のトンネルの開始時）。これを行うことで、MPLS Tracerouteパケットは外側のトンネルでは期限切れになり、外側のトンネルはトレースされません。
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. 新しい外側のLSPの詳細を公開したくない場合は、NIL FECを使用してそれらの詳細を隠すことができます。NIL 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は、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルスイッチパス（LSP）PINGパラメーター「TLV」、およびサブTLVS「サブレジストリ」からTLVタイプの値を次のTLVに割り当てました。
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です。範囲0-16383および32768-49161の割り当ては、[RFC3692]で定義されている標準アクションを介して行われます。16384-31743および49162-64511の範囲の割り当ては、必要な仕様を介して行われます[RFC4379]。範囲31744- 32767および64512-65535の値は、ベンダーの私的使用のためであり、割り当てられてはなりません。Sub-TLVにベンダーの私的使用の範囲に分類されるタイプがある場合、長さは少なくとも4でなければならず、最初の4つのオクテットは、ネットワークオクテットの順序でベンダーのSMIエンタープライズコードでなければなりません。残りの値フィールドはベンダーのプライベートです。
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は、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）pingパラメーター「レジストリ」、「リターンコード」サブレジストリ、次のように、標準アクション値を使用して「レジストリ」から新しいリターンコード値を割り当てました。
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.
著者は、Yakov RekhterとAdrian Farrelにドキュメントに関する提案に感謝したいと思います。
[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月。
[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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Yasukawa、S。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[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. Farrel、「一般化されたマルチプロトコルラベル交通工学（GMPLS TE）を使用したラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLS Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、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] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
Authors' Addresses
著者のアドレス
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
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Avenue Sunnyvale、CA 94089 US
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
URI: www.juniper.net
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 US
ジョージスワローシスコシステム1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719米国
EMail: swallow@cisco.com
URI: www.cisco.com