[要約] RFC 7110は、Return Path Specified Label Switched Path (LSP) Pingに関する仕様であり、LSPの経路を確認するためのメカニズムを提供します。目的は、ネットワークのトラブルシューティングやパフォーマンスの監視を支援することです。
Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7110 W. Cao
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 S. Ning
Tata Communications
F. Jounay
Orange CH
S. Delord
January 2014
Return Path Specified Label Switched Path (LSP) Ping
Return Path Specified Label Switched Path（LSP）Ping
Abstract
概要
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.
このドキュメントでは、「LSP ping」と呼ばれるマルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）のデータプレーン障害検出プロトコルの拡張機能を定義します。これらの拡張により、エコー応答のリターンパスに使用するLSPを選択できます。特定のリターンパスを適用すると、双方向接続を確認し、LSP pingの堅牢性を高めることができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7110.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7110で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Problem Statements and Solution Overview ........................3
3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
3.2. Limitations of Existing Mechanisms for Handling
Unreliable Return Paths ....................................4
4. Extensions ......................................................5
4.1. Reply via Specified Path Mode ..............................6
4.2. Reply Path (RP) TLV ........................................6
4.3. Tunnel Sub-TLVs ............................................8
4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
4.3.3. Static Tunnel Sub-TLV ..............................12
4.4. Reply TC TLV ..............................................12
5. Theory of Operation ............................................13
5.1. Sending an Echo Request ...................................14
5.2. Receiving an Echo Request .................................14
5.3. Sending an Echo Reply .....................................15
5.4. Receiving an Echo Reply ...................................16
5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
7.1. TLVs ......................................................17
7.2. New Target FEC Stack Sub-TLVs .............................17
7.3. New Reply Mode ............................................17
7.4. Reply Path Return Code ....................................18
8. Contributors ...................................................19
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping" [RFC4379] that can be used to specify the return paths for the echo reply message, increasing the robustness of LSP ping, reducing the opportunity for error, and improving the reliability of the echo reply message. A new Reply Mode, which is referred to as "Reply via Specified Path", is added and a new Type-Length-Value (TLV), which is referred to as "Reply Path (RP) TLV", is defined in this memo. The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document.
このドキュメントでは、エコー応答メッセージのリターンパスを指定するために使用できる「LSP ping」[RFC4379]と呼ばれるマルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）のデータプレーン障害検出プロトコルの拡張機能を定義します。 LSP pingの堅牢性を高め、エラーの機会を減らし、エコー応答メッセージの信頼性を向上させます。 「指定されたパスを介した返信」と呼ばれる新しい返信モードが追加され、「返信パス（RP）TLV」と呼ばれる新しいType-Length-Value（TLV）がこのメモで定義されています。 。このドキュメントで定義されている手順は、現在「ping」モードにのみ適用されます。 「traceroute」モードは、このドキュメントの範囲外です。
In this document, the term bidirectional LSP includes the co-routed bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction) that are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and MPLS Transport Profile (MPLS-TP) scenarios.
このドキュメントでは、双方向LSPという用語には、[RFC3945]で定義されている共ルーティング双方向LSPと、LSPの入口で相互に関連付けられている単方向LSPのペア（各方向に1つ）から構成される関連双方向LSPが含まれます/ egress points [RFC5654]。このドキュメントで定義されているメカニズムは、IP / MPLSとMPLSトランスポートプロファイル（MPLS-TP）の両方のシナリオに適用できます。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
MPLS LSP ping is defined in [RFC4379]. It can be used to detect data-path failures in all MPLS LSPs.
MPLS LSP pingは[RFC4379]で定義されています。すべてのMPLS LSPでデータパス障害を検出するために使用できます。
LSPs are increasingly being deployed to provide bidirectional services. The co-routed bidirectional LSP is defined in [RFC3945], and the associated bidirectional LSP is defined in [RFC5654]. With the deployment of such services, operators have a desire to test both directions of a bidirectional LSP in a single operation.
LSPは、双方向サービスを提供するためにますます展開されています。コルーテッド双方向LSPは[RFC3945]で定義されており、関連する双方向LSPは[RFC5654]で定義されています。このようなサービスの導入により、オペレーターは双方向LSPの両方向を1回の操作でテストしたいと考えています。
Additionally, when testing a single direction of an LSP (either a unidirectional LSP or a single direction of a bidirectional LSP) using LSP ping, the validity of the result may be affected by the success of delivering the echo reply message. Failure to exchange these messages between the egress Label Switching Router (LSR) and the ingress LSR can lead to false negatives where the LSP under test is reported as "down" even though it is functioning correctly.
さらに、LSP pingを使用してLSPの単一方向（単方向LSPまたは双方向LSPの単一方向）をテストする場合、結果の有効性は、エコー応答メッセージの配信の成功に影響されることがあります。出力ラベルスイッチングルーター（LSR）と入力LSRの間でこれらのメッセージを交換しないと、テスト中のLSPが正しく機能していても、「ダウン」と報告される偽陰性につながる可能性があります。
With the existing LSP ping mechanisms, as defined in [RFC4379], operators have to enable LSP detection on each of the two ends of a bidirectional LSP independently. This not only doubles the workload for the operators but may also bring additional difficulties when checking the backward direction of the LSP under the following condition:
[RFC4379]で定義されている既存のLSP pingメカニズムでは、オペレーターは双方向LSPの両端のそれぞれでLSP検出を有効にする必要があります。これにより、オペレーターの作業負荷が2倍になるだけでなく、次の条件下でLSPの逆方向をチェックするときにさらに問題が発生する可能性があります。
The LSR that the operator logged on to perform the checking operations might not have out-of-band connectivity to the LSR at the far end of the LSP. That can mean it is not possible to check the return direction of a bidirectional LSP in a single operation -- the operator must log on to the LSR at the other end of the LSP to test the return direction.
オペレーターが検査操作を実行するためにログオンしたLSRには、LSPの遠端でLSRへの帯域外接続がない場合があります。つまり、単一の操作で双方向LSPの戻り方向を確認することは不可能です。オペレーターは、LSPのもう一方の端にあるLSRにログオンして戻り方向をテストする必要があります。
Associated bidirectional LSPs have the same issues as those listed for co-routed bidirectional LSPs.
関連付けられた双方向LSPには、コルートされた双方向LSPについてリストされているものと同じ問題があります。
This document defines a mechanism to allow the operator to request that both directions of a bidirectional LSP be tested by a single LSP ping message exchange.
このドキュメントでは、オペレーターが双方向LSPの双方向を単一のLSP pingメッセージ交換でテストすることを要求できるようにするメカニズムを定義しています。
3.2. Limitations of Existing Mechanisms for Handling Unreliable Return Paths
3.2. 信頼できないリターンパスを処理するための既存のメカニズムの制限
[RFC4379] defines four Reply Modes:
[RFC4379]は4つの応答モードを定義しています：
1. Do not reply 2. Reply via an IPv4/IPv6 UDP packet 3. Reply via an IPv4/IPv6 UDP packet with Router Alert 4. Reply via application level control channel
1. 返信しないでください。2. IPv4 / IPv6 UDPパケット経由で返信します。3.ルータアラート付きのIPv4 / IPv6 UDPパケット経由で返信します。4.アプリケーションレベルの制御チャネル経由で返信します。
Obviously, the issue of the reliability of the return path for an echo reply message does not apply in the first of these cases.
明らかに、エコー応答メッセージの戻りパスの信頼性の問題は、これらの最初のケースには当てはまりません。
[RFC4379] states that the third mode may be used when the IP return path is deemed unreliable. This mode of operation requires that all intermediate nodes support the Router Alert option and understand how to forward MPLS echo replies. This is a rigorous requirement in deployed IP/MPLS networks, especially since the return path may be through legacy IP-only routers.
[RFC4379]は、IPリターンパスが信頼できないと見なされたときに3番目のモードが使用される可能性があると述べています。この動作モードでは、すべての中間ノードがルーターアラートオプションをサポートし、MPLSエコー応答を転送する方法を理解している必要があります。これは、特に戻りパスがレガシーIP専用ルーターを経由する可能性があるため、展開されたIP / MPLSネットワークでの厳しい要件です。
In any case, the use of Reply Modes 2 or 3 cannot guarantee the delivery of echo responses through an IP network that is fundamentally unreliable. The failure to deliver echo response messages can lead to false negatives, making it appear that the LSP has failed.
いずれの場合でも、応答モード2または3を使用しても、根本的に信頼できないIPネットワークを介したエコー応答の配信は保証されません。エコー応答メッセージの配信に失敗すると、偽陰性になり、LSPが失敗したように見えることがあります。
Allowing the ingress LSR to control the path used for echo reply messages enables an operator to apply an extra level of deterministic process to the LSP ping test. For example, when testing an LSP, Reply Mode 2 is used at the beginning but no echo reply is received. When failure of the return path is suspected, the operator can initiate another LSP ping with the Reply Mode defined in this document and specify a different return path that is deemed workable to complete the test.
入力LSRがエコー応答メッセージに使用されるパスを制御できるようにすると、オペレーターはLSP pingテストに追加のレベルの確定的プロセスを適用できます。たとえば、LSPをテストする場合、最初に応答モード2が使用されますが、エコー応答は受信されません。リターンパスの障害が疑われる場合、オペレーターは、このドキュメントで定義されている応答モードを使用して別のLSP pingを開始し、テストを完了するために実行可能と見なされる別のリターンパスを指定できます。
This document defines extensions to LSP ping that can be used to specify the return paths of the echo reply message in an echo request message.
このドキュメントでは、エコー要求メッセージでエコー応答メッセージのリターンパスを指定するために使用できるLSP pingの拡張機能を定義します。
LSP ping, defined in [RFC4379], is carried out by sending an echo request message. It carries the Forwarding Equivalence Class (FEC) information of the LSP being tested. The FEC information indicates which MPLS path is being verified along the same data path as other normal data packets belonging to the FEC.
[RFC4379]で定義されているLSP pingは、エコー要求メッセージを送信することによって実行されます。テスト対象のLSPのForwarding Equivalence Class（FEC）情報が含まれています。 FEC情報は、FECに属する他の通常のデータパケットと同じデータパスに沿って検証されているMPLSパスを示します。
LSP ping [RFC4379] defines four Reply Modes that are used to direct the egress LSR in how to send back an echo reply. This document defines a new Reply Mode, the "Reply via Specified Path" mode. This new mode is used to direct the egress LSR of the tested LSP to send the echo reply message back along the path specified in the echo request message.
LSP ping [RFC4379]は、エコー応答の返信方法で出力LSRを指示するために使用される4つの応答モードを定義します。このドキュメントでは、新しい返信モードである「指定されたパスを介した返信」モードを定義しています。この新しいモードは、テストされたLSPの出力LSRに、エコー要求メッセージで指定されたパスに沿ってエコー応答メッセージを送信するように指示するために使用されます。
In addition, two new TLVs, the "Reply Path (RP) TLV" and "Reply Traffic Class (TC) TLV" [RFC5462], are defined in this document. The Reply Path TLV contains one or more nested sub-TLVs that can be used to carry the specified return path information to be used by the echo reply message.
さらに、このドキュメントでは、「Reply Path（RP）TLV」と「Reply Traffic Class（TC）TLV」[RFC5462]の2つの新しいTLVが定義されています。応答パスTLVには、1つ以上のネストされたサブTLVが含まれています。これらのサブTLVを使用して、エコー応答メッセージで使用される指定の戻りパス情報を運ぶことができます。
A new Reply Mode is defined to be carried in the Reply Mode field of the echo request message.
新しい応答モードは、エコー要求メッセージの応答モードフィールドで伝送されるように定義されています。
The value of the Reply via Specified Path mode is 5 (This has been allocated by IANA using early allocation and is to be confirmed by IANA).
指定パスモードを介した応答の値は5です（これは、早期割り当てを使用してIANAによって割り当てられ、IANAによって確認されます）。
Value Meaning
----- -------
5 Reply via Specified Path
The Reply via Specified Path mode is used to request that the remote LSR receiving the echo request message sends back the echo reply message along the specified paths carried in the Reply Path TLV.
指定パス経由の返信モードは、エコー要求メッセージを受信するリモートLSRが、返信パスTLVで運ばれる指定されたパスに沿ってエコー返信メッセージを返信するように要求するために使用されます。
The Reply Path (RP) TLV is an optional TLV within the LSP ping protocol. However, if the Reply via Specified Path mode requested, as described in Section 4.1, the Reply Path (RP) TLV MUST be included in an echo request message, and its absence is treated as a malformed echo request, as described in [RFC4379]. Furthermore, if a Reply Path (RP) TLV is included in an echo request message, a Reply Path (RP) TLV MUST be included in the corresponding echo reply message sent by an implementation that is conformant to this specification.
応答パス（RP）TLVは、LSP pingプロトコル内のオプションのTLVです。ただし、セクション4.1で説明されているように、指定されたパスモードでの応答が要求された場合、[RFC4379]で説明されているように、応答パス（RP）TLVがエコー要求メッセージに含まれている必要があり、その欠如は不正なエコー要求として扱われます。 。さらに、応答パス（RP）TLVがエコー要求メッセージに含まれている場合、応答パス（RP）TLVは、この仕様に準拠する実装によって送信される対応するエコー応答メッセージに含まれている必要があります。
The Reply Path (RP) TLV carries the specified return path that the echo reply message is required to follow. The format of Reply Path TLV is as follows:
応答パス（RP）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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path return code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reply Path TLV
図1：応答パスTLV
Reply Path TLV Type: It is 2 octets in length, and the type value is 21.
応答パスTLVタイプ：長さは2オクテットで、タイプ値は21です。
Length: It is 2 octets in length. It defines the length in octets of the Reply Path return code, Flags, and Reply Path fields.
長さ：長さは2オクテットです。これは、応答パスの戻りコード、フラグ、および応答パスフィールドの長さをオクテット単位で定義します。
Reply Path return code: The Reply Path return code field is 2 octets in length. It is defined for the egress LSR of the forward LSP to report the results of Reply Path TLV processing and return path selection. This field MUST be set to zero in a Reply Path TLV carried on an echo request message and MUST be ignored on receipt. This document defines the following Reply Path return codes for inclusion in a Reply Path TLV carried on an echo reply:
応答パスの戻りコード：応答パスの戻りコードフィールドの長さは2オクテットです。転送LSPの出力LSRが応答パスTLV処理と戻りパスの選択の結果を報告するように定義されています。このフィールドは、エコー要求メッセージで伝送される応答パスTLVでゼロに設定する必要があり、受信時に無視する必要があります。このドキュメントでは、エコー応答で伝送される応答パスTLVに含めるための次の応答パス戻りコードを定義します。
Value Meaning
------ ----------------------
0x0000 Reserved, MUST NOT be used
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental Use
Flags: It is also 2 octets in length, it is used to notify the
egress how to process the Reply Paths field when performing return
path selection. The Flags field is a bit vector and has following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flags
A (Alternative path): the egress LSR MUST select a non-default path as the return path. This is very useful when reverse default path problems are suspected that can be confirmed when the echo reply is forced to follow a non-default return path. Here, the default path refers to the path that the egress LSR will use to send the echo reply when Reply Mode 2 or 3 is used. If A bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored.
A（代替パス）：出力LSRは、デフォルト以外のパスを戻りパスとして選択する必要があります。これは、エコー応答がデフォルト以外の戻りパスをたどるように強制されたときに確認できるデフォルトのパスの逆問題が疑われる場合に非常に役立ちます。ここで、デフォルトパスとは、応答モード2または3が使用されている場合に、出力LSRがエコー応答の送信に使用するパスを指します。 Aビットが設定されている場合、特定の応答パスサブTLVを伝送する必要はありません。受信すると、サブTLVは無視されるべきです（SHOULD）。
B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP. If B bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored.
B（双方向）：戻りパスは、テストされた双方向LSPの逆方向に従う必要があります。 Bビットが設定されている場合、特定の応答パスサブTLVを伝送する必要はなく、受信時にサブTLVを無視する必要があります（SHOULD）。
The A flag and B flag MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" MUST be returned.
AフラグとBフラグの両方を設定することはできません。それ以外の場合は、RP戻りコードが「不正な応答パスTLVを受信した」に設定されたエコー応答を返す必要があります。
Reply Path: It is used to describe the return path that an echo reply will be send along. It is variable in length and can contain zero, one or more Target FEC sub-TLVs [RFC4379]. In an echo request, it carries sub-TLVs that describe the specified path that the echo reply message is required to follow. In an echo reply, the sub-TLVs describe the FEC Stack information of the return path (when the return path is an MPLS path) that the echo reply will be sent along.
返信パス：エコー返信が送信される返信パスを記述するために使用されます。長さは可変で、ゼロ、1つ以上のターゲットFECサブTLVを含めることができます[RFC4379]。エコー要求では、エコー応答メッセージがたどる必要がある指定されたパスを記述するサブTLVを伝送します。エコー応答では、サブTLVはエコー応答が一緒に送信される戻りパス（戻りパスがMPLSパスの場合）のFECスタック情報を記述します。
[RFC4379] has already defined several Target FEC sub-TLVs, the Target FEC sub-TLVs provide a good way to identify a specific return path. The Reply Path TLV can carry any (existing and future defined) sub-TLV defined for use in the Target FEC Stack TLV to specify the return path.
[RFC4379]はすでにいくつかのターゲットFECサブTLVを定義しています。ターゲットFECサブTLVは、特定のリターンパスを識別する良い方法を提供します。応答パスTLVは、ターゲットFECスタックTLVで使用するために定義された（既存および将来定義された）サブTLVを伝送して、リターンパスを指定できます。
This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One usage of these generic RSVP Tunnel sub-TLVs is when LSP ping is used to periodically verify the control plane against the data plane [RFC5884], using a Tunnel other than a particular LSP can avoid the impact of an LSP identifier changing when Make-Before-Break (MBB) is deployed. These sub-TLVs also can be used in the Reply Path TLV to allow the operator to specify a more generic tunnel FEC other than a particular LSP as the return path.
このドキュメントでは、IPv4 RSVPトンネルサブTLV、IPv6 RSVPトンネルサブTLV、静的トンネルサブTLVの3つの新しいターゲットFECサブTLVを定義しています。これらの一般的なRSVPトンネルサブTLVの1つの使用法は、LSP pingを使用してデータプレーン[RFC5884]に対してコントロールプレーンを定期的に検証する場合です。特定のLSP以外のトンネルを使用すると、メイク時にLSP識別子の変更による影響を回避できます。 Before-Break（MBB）がデプロイされます。これらのサブTLVを応答パスTLVで使用して、オペレーターが特定のLSP以外のより一般的なトンネルFECを戻りパスとして指定できるようにすることもできます。
No assignments of sub-TLVs are made directly for TLV Type 21, the sub-TLV space and assignments for TLV Type 21 will be the same as that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 MUST be kept the same. Any new sub-type added to TLV Type 1 MUST apply to the TLV Type 21 as well.
TLVタイプ21のサブTLVの割り当ては直接行われません。サブTLVスペースおよびTLVタイプ21の割り当ては、TLVタイプ1の割り当てと同じになります。TLVタイプ1およびTLVタイプ21のサブタイプは保持する必要があります。同じ。 TLVタイプ1に追加された新しいサブタイプは、TLVタイプ21にも適用する必要があります。
With the Return Path TLV flags and the sub-TLVs defined for the Target FEC Stack TLV and in this document, it could provide the following options for return paths specifying:
ターゲットFECスタックTLVに対して定義されたリターンパスTLVフラグとサブTLVを使用して、このドキュメントでは、リターンパスを指定するための次のオプションを提供できます。
1. a particular LSP as return path
1. リターンパスとしての特定のLSP
- use those sub-TLVs defined for the Target FEC Stack TLV
- ターゲットFECスタックTLVに定義されたサブTLVを使用する
2. a more generic tunnel FEC as return path - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of this document
2. リターンパスとしてのより一般的なトンネルFEC-このドキュメントのセクション4.3.1、セクション4.3.2、セクション4.3.3で定義されているIPv4 / IPv6 RSVPおよび静的トンネルサブTLVを使用します
3. the reverse path of the bidirectional LSP as return path
3. 戻りパスとしての双方向LSPの逆パス
- use B bit defined in Section 4.2 of this document.
- このドキュメントのセクション4.2で定義されているBビットを使用します。
4. Force return path to non-default path
4. パスをデフォルト以外のパスに強制的に戻す
- use A bit defined in Section 4.2 of this document.
- このドキュメントのセクション4.2で定義されているビットを使用します。
The format of the IPv4 RSVP Tunnel sub-TLV is as follows:
IPv4 RSVPトンネルサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 RSVP Tunnel Sub-TLV
図3：IPv4 RSVPトンネルサブTLV
The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV that is defined in Section 3.2.3 of [RFC4379]. All fields have the same semantics as defined in [RFC4379] except that the LSP-ID field is omitted and a new Flags field is defined.
IPv4 RSVPトンネルサブTLVは、[RFC4379]のセクション3.2.3で定義されているRSVP IPv4 FEC TLVから派生しています。 LSP-IDフィールドが省略され、新しいフラグフィールドが定義されていることを除いて、すべてのフィールドは[RFC4379]で定義されているのと同じセマンティクスを持っています。
The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the recommended type value is 26.
IPv4 RSVPトンネルサブTLVタイプフィールドの長さは2オクテットで、推奨されるタイプ値は26です。
The Flags field is 2 octets in length, it is used to notify the egress LSR how to choose the return path. The Flags field is a bit vector and has following format:
フラグフィールドの長さは2オクテットで、戻りパスの選択方法を出力LSRに通知するために使用されます。 Flagsフィールドはビットベクトルであり、次の形式になります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Tunnel Flags
図4：トンネルフラグ
P (Primary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the primary LSP.
P（プライマリ）：戻りパスは、指定されたトンネルに属するLSPから選択する必要があり、LSPはプライマリLSPでなければなりません。
S (Secondary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the secondary LSP. Primary and secondary LSPs are defined in [RFC4872].
S（セカンダリ）：戻りパスは、指定されたトンネルに属するLSPから選択する必要があり、LSPはセカンダリLSPでなければなりません。プライマリおよびセカンダリLSPは[RFC4872]で定義されています。
P bit and S bit MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" SHOULD be returned. If P bit and S bit are both not set, the return path could be any one of the LSPs from the same Tunnel.
PビットとSビットの両方を設定してはなりません（MUST NOT）。それ以外の場合は、RP戻りコードが「不正な応答パスTLVを受信した」に設定されたエコー応答を返す必要があります。 PビットとSビットの両方が設定されていない場合、戻りパスは同じトンネルからのLSPのいずれかになる可能性があります。
The format of the IPv6 RSVP Tunnel sub-TLV is as follows:
IPv6 RSVPトンネルサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 RSVP Tunnel Sub-TLV
図5：IPv6 RSVPトンネルサブTLV
The IPv6 RSVP Tunnel sub-TLV is derived from the RSVP IPv6 FEC TLV that is defined in Section 3.2.4 of [RFC4379]. All fields have the same semantics as defined in [RFC4379] except that the LSP-ID field is omitted and a new Flags field is defined.
IPv6 RSVPトンネルサブTLVは、[RFC4379]のセクション3.2.4で定義されているRSVP IPv6 FEC TLVから派生しています。 LSP-IDフィールドが省略され、新しいフラグフィールドが定義されていることを除いて、すべてのフィールドは[RFC4379]で定義されているのと同じセマンティクスを持っています。
The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the type value is 27.
IPv6 RSVPトンネルサブTLVタイプフィールドの長さは2オクテットで、タイプ値は27です。
The Flags field is 2 octets in length and is identical to that described in Section 4.3.1.
Flagsフィールドの長さは2オクテットで、セクション4.3.1で説明したものと同じです。
The format of the Static RSVP Tunnel sub-TLV is as follows. The value fields are taken from the definitions in [RFC6370].
Static RSVP Tunnel sub-TLVのフォーマットは次のとおりです。値フィールドは、[RFC6370]の定義から取得されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Static Tunnel Sub-TLV
図6：スタティックトンネルサブTLV
The Flags field is 2 octets in length and is identical to that described in Section 4.3.1.
Flagsフィールドの長さは2オクテットで、セクション4.3.1で説明したものと同じです。
The sub-TLV type value is 28.
サブTLVタイプの値は28です。
Reply TOS Byte TLV [RFC4379] is used by the originator of the echo request to request that an echo reply be sent with the IP header TOS byte set to the value specified in the TLV. Similarly, in this document, a new TLV, Reply TC TLV, is defined and MAY be used by the originator of the echo request to request that an echo reply be sent with the TC bits of the return path LSP set to the value specified in this TLV. The Reply TC TLV is not limited to the Reply Mode specified in this document (Reply via Specified Path) but may be used in all the other Reply Modes as well. The format of Reply TC TLV is as follows:
応答TOSバイトTLV [RFC4379]は、エコー要求の発信者がIPヘッダーのTOSバイトをTLVで指定された値に設定してエコー応答を送信することを要求するために使用されます。同様に、このドキュメントでは、新しいTLVであるReply TC TLVが定義されており、エコー要求の発信者がエコー応答を送信するように要求することができます。このTLV。応答TC TLVは、このドキュメントで指定されている応答モード（指定されたパスを介した応答）に限定されず、他のすべての応答モードでも使用できます。 Reply TC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply TC TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Reply TC TLV
図7：応答TC TLV
The Reply TC TLV Type field is 2 octets in length, and the type value is 22.
Reply TC TLV Typeフィールドの長さは2オクテットで、タイプ値は22です。
The Length field is 2 octets in length, the value of length field is fixed 4 octets.
長さフィールドの長さは2オクテットであり、長さフィールドの値は4オクテットに固定されています。
The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document.
このドキュメントで定義されている手順は、現在「ping」モードにのみ適用されます。 「traceroute」モードは、このドキュメントの範囲外です。
In [RFC4379], the echo reply is used to report the LSP checking result to the LSP ping initiator. This document defines a new Reply Mode and a new TLV (Reply Path TLV) that enable the LSP ping initiator to specify or constrain the return path of the echo reply. Similarly, the behavior of echo reply is extended to detect the requested return path by looking at a specified path FEC TLV. This enables LSP ping to detect failures in both directions of a path with a single operation; of course, this cuts in half the operational steps required to verify the end-to-end bidirectional connectivity and integrity of an LSP.
[RFC4379]では、エコー応答を使用して、LSPチェック結果をLSP pingイニシエーターに報告します。このドキュメントでは、LSP pingイニシエーターがエコー応答のリターンパスを指定または制約できるようにする新しい応答モードと新しいTLV（応答パスTLV）を定義します。同様に、エコー応答の動作は、指定されたパスFEC TLVを調べることにより、要求された戻りパスを検出するように拡張されています。これにより、LSP pingは、単一の操作でパスの両方向の障害を検出できます。もちろん、これにより、LSPのエンドツーエンドの双方向接続と整合性を検証するために必要な操作手順が半分になります。
When the return path is an MPLS path, the echo reply MUST carry the FEC Stack information in a Reply Path TLV to test the return MPLS LSP path. The destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this possibility the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6, and the IP Time to Live (TTL) MUST be set 1, and the TTL in the outermost label MUST be set to 255.
リターンパスがMPLSパスの場合、エコー応答は、返信MPLS LSPパスをテストするために、応答パスTLVでFECスタック情報を伝達する必要があります。エコー応答メッセージの宛先IPアドレスは、転送の決定に使用してはなりません（MUST NOT）。この可能性を回避するには、指定されたリターンパスに沿って送信されるエコー応答メッセージの宛先IPアドレスを、IPv4の場合は127/8の範囲、または0：0：0：0：0：FFFF：127.0.0.0の番号に設定する必要があります。 / 104 for IPv6、およびIP Time to Live（TTL）を1に設定する必要があり、最も外側のラベルのTTLを255に設定する必要があります。
When the return path is a pure IP forwarding path, the procedures defined in [RFC4379] (the destination IP address is copied from the source IP address) apply unchanged.
リターンパスが純粋なIP転送パスである場合、[RFC4379]で定義されている手順（宛先IPアドレスがソースIPアドレスからコピーされる）は変更されずに適用されます。
When sending an echo request, in addition to the rules and procedures defined in Section 4.3 of [RFC4379], the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV MUST be carried in the echo request message correspondingly. The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply.
エコーリクエストを送信するときは、[RFC4379]のセクション4.3で定義されたルールと手順に加えて、エコーリクエストの返信モードを「指定されたパスを介して返信」に設定する必要があり、返信パスTLVを対応して要求メッセージをエコーします。応答パスTLVには、出力LSRが応答に使用する必要がある戻りパスを識別するための1つまたは複数の応答パスサブTLVが含まれています。
For a bidirectional LSP, since the ingress LSR and egress LSR of a bidirectional LSP are aware of the relationship between the forward and backward direction LSPs, only the B bit SHOULD be set in the Reply Path TLV. If the operator wants the echo reply to be sent along a path other than the reverse direction of the bidirectional LSP, the A bit SHOULD be set or another FEC sub-TLV SHOULD be carried in the Reply Path TLV instead, and the B bit MUST be clear.
双方向LSPの場合、双方向LSPの入力LSRと出力LSRは順方向と逆方向のLSP間の関係を認識しているため、応答パスTLVでBビットのみを設定する必要があります（SHOULD）。オペレーターが双方向LSPの逆方向以外のパスに沿ってエコー応答を送信したい場合は、Aビットを設定するか、代わりに別のFECサブTLVを応答パスTLVで伝送する必要があります（Bビットは必須）。明確にする。
In some cases, operators may want to treat two unidirectional LSPs (one for each direction) as a pair. There may not be any binding relationship between the two LSPs. Using the mechanism defined in this document, operators can run LSP ping one time from one end to complete the failure detection on both unidirectional LSPs. To accomplish this, the echo request message MUST carry (in the Reply Path TLV) a FEC sub-TLV that belongs to the backward LSP.
場合によっては、オペレーターは2つの単方向LSP（各方向に1つ）をペアとして扱いたいことがあります。 2つのLSPの間に拘束関係はありません。このドキュメントで定義されているメカニズムを使用して、オペレータはLSP pingを一方の端から1回実行して、両方の単方向LSPで障害検出を完了することができます。これを達成するために、エコー要求メッセージは（応答パスTLVで）逆方向LSPに属するFECサブTLVを運ぶ必要があります。
"Ping" mode processing, as defined in Section 4.4 of [RFC4379], applies in this document. In addition, when an echo request is received, if the egress LSR does not know the Reply Mode defined in this document, an echo reply with the return code set to "Malformed echo request received" and the Subcode set to zero will be send back to the ingress LSR according to the rules of [RFC4379]. If the egress LSR knows the Reply Mode, according to the Reply Path TLV, it SHOULD find and select the desired return path. If there is a matched path, an echo reply with a Reply Path TLV that identifies the return path SHOULD be sent back to the ingress LSR, the Reply Path return code SHOULD be set to "The echo reply was sent successfully using the specified Reply Path". If there is no such path, an echo reply with the Reply Path TLV SHOULD be sent back to the ingress LSR, the Reply Path return code SHOULD be set to the relevant code (defined in Section 4.2) for the real situation to reflect the result of Reply Path TLV processing and return path selection. For example, if the specified LSP is not found, the egress then chooses another LSP as the return path to send the echo reply, the Reply Path return code SHOULD be set to "The specified reply path was not found, the echo reply was sent via another LSP", and if the egress chooses an IP path to send the echo reply, the Reply Path return code SHOULD be set to "The specified Reply Path was not found, the echo reply was sent via pure IP forwarding (non-MPLS) path". If there is an unknown sub-TLV in the received Reply Path TLV, the Reply Path return code SHOULD be set to "One or more of the sub-TLVs in the Reply Path TLV were not understood".
[RFC4379]のセクション4.4で定義されている「Ping」モードの処理は、このドキュメントに適用されます。さらに、エコー要求を受信したときに、出力LSRがこのドキュメントで定義されている応答モードを認識していない場合、戻りコードが「不正なエコー要求を受信しました」に設定され、サブコードがゼロに設定されたエコー応答が返送されます。 [RFC4379]のルールに従って、イングレスLSRに。出力LSRが応答モードを知っている場合、応答パスTLVに従って、目的の戻りパスを見つけて選択する必要があります（SHOULD）。一致するパスがある場合、戻りパスを識別する返信パスTLVを持つエコー応答を入力LSRに送り返す必要があります（SHOULD）、返信パス戻りコードは、「指定された返信パスを使用して、エコー返信が正常に送信されました」そのようなパスがない場合は、応答パスTLVを含むエコー応答を入力LSRに送信する必要があります（SHOULD）。応答パスの戻りコードは、結果を反映する実際の状況に関連するコード（セクション4.2で定義）に設定する必要があります（SHOULD）。応答パスTLV処理と戻りパスの選択。たとえば、指定されたLSPが見つからない場合、出力はエコー応答を送信するための戻りパスとして別のLSPを選択します。応答パスの戻りコードは、「指定された応答パスが見つからなかったため、エコー応答が送信されました。別のLSPを介して」、および出力がエコー応答を送信するためにIPパスを選択する場合、応答パスの戻りコードは「指定された応答パスが見つかりませんでした。エコー応答は純粋なIP転送（非MPLS ） 道"。受信した返信パスTLVに不明なサブTLVがある場合、返信パスのリターンコードは「返信パスTLVの1つ以上のサブTLVが認識されなかった」に設定する必要があります（SHOULD）。
If the A bit of the Reply Path TLV in a received echo request message is set, the egress LSR SHOULD send the echo reply along a non-default return path.
受信したエコー要求メッセージの応答パスTLVのAビットが設定されている場合、出力LSRはデフォルト以外の戻りパスに沿ってエコー応答を送信する必要があります（SHOULD）。
If the B bit of the Reply Path TLV in a received echo request message is set, the egress LSR SHOULD send the echo reply along the reverse direction of the bidirectional LSP.
受信したエコー要求メッセージの応答パスTLVのBビットが設定されている場合、出力LSRは双方向LSPの逆方向に沿ってエコー応答を送信する必要があります（SHOULD）。
In addition, the FEC validate results of the forward path LSP SHOULD NOT affect the egress LSR continue to test return path LSP.
さらに、フォワードパスLSPのFEC検証結果は、出力LSRに影響を与えてはならず（SHOULD NOT）、リターンパスLSPのテストを続行します。
As described in [RFC4379], the echo reply message is a UDP packet, and it MUST be sent only in response to an MPLS echo request. The source IP address is a valid IP address of the replier, the source UDP port is the well-know UDP port for LSP ping.
[RFC4379]で説明されているように、エコー応答メッセージはUDPパケットであり、MPLSエコー要求への応答としてのみ送信されなければなりません（MUST）。送信元IPアドレスは応答者の有効なIPアドレスであり、送信元UDPポートはLSP pingの既知のUDPポートです。
When the return path is an MPLS LSP, the destination IP address of the echo reply message is copied from the destination IP address of the echo request, and the destination UDP port is copied from the source UDP port of the echo request. The IP TTL MUST be set to 1, the TTL in the outermost label MUST be set to 255.
リターンパスがMPLS LSPの場合、エコー応答メッセージの宛先IPアドレスはエコー要求の宛先IPアドレスからコピーされ、宛先UDPポートはエコー要求の送信元UDPポートからコピーされます。 IP TTLは1に設定する必要があり、最も外側のラベルのTTLは255に設定する必要があります。
When the return path is a pure IP forwarding path, the same as defined in [RFC4379], the destination IP address and UDP port are copied from the source IP address and source UDP port of the echo request.
[RFC4379]で定義されているのと同じように、戻りパスが純粋なIP転送パスである場合、宛先IPアドレスとUDPポートは、エコー要求のソースIPアドレスとソースUDPポートからコピーされます。
When sending the echo reply, a Reply Path TLV that identifies the return path MUST be carried, the Reply Path return code SHOULD be set to relevant code that reflects results about how the egress processes the Reply Path TLV in a previous received echo request message and return path selection. By carrying the Reply Path TLV in an echo reply, it gives the ingress LSR enough information about the reverse direction of the tested path to verify the consistency of the data plane against control plane. Thus, a single LSP ping could achieve both directions of a path test. If the return path is pure IP path, no sub-TLVs are carried in the Reply Path TLV.
エコー応答を送信するときは、戻りパスを識別する応答パスTLVを伝送する必要があります。応答パス戻りコードは、前に受信したエコー要求メッセージで出力が応答パスTLVを処理する方法に関する結果を反映する関連コードに設定する必要があります（SHOULD）。パス選択を返します。エコー応答で応答パスTLVを伝送することにより、テストパスの逆方向に関する十分な情報を入力LSRに提供し、コントロールプレーンに対するデータプレーンの整合性を検証します。したがって、1つのLSP pingでパステストの両方向を実現できます。戻りパスが純粋なIPパスの場合、応答パスTLVでサブTLVは伝送されません。
The rules and process defined in Section 4.6 of [RFC4379] apply here. When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. The ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here.
[RFC4379]のセクション4.6で定義されたルールとプロセスがここに適用されます。エコー応答が受信されたとき、応答モードが「指定されたパスを介した応答」であり、応答パスの戻りコードが「指定された応答パスを使用してエコー応答が正常に送信されました」であり、戻りパスがMPLS LSPである場合。入力LSRは、エコー要求を受信するときに出力LSRが行うように（応答パスTLVで伝送される戻りパスのFECスタック情報に基づいて）FEC検証を実行する必要があります。FEC検証プロセス（「ping」モードに関連）は、 [RFC4379]のセクション4.4.1がここに適用されます。
When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. It is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode, the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined [RFC4379].
エコー応答が受信され、戻りコードが「不正なエコー要求を受信しました」に設定され、サブコードがゼロに設定された場合。出力LSRが「指定されたパスを介した応答」応答モードを認識していない可能性があります。オペレーターは、定義された4つの応答モードのいずれかを使用して別のLSP pingを再実行することを選択できます[RFC4379]。
On receipt of an echo reply with Reply Path return code in the Reply Path TLV set to "The specified reply path was not found, ...", it means that the egress LSR could not find a matched return path as specified. Operators may choose to specify another LSP as the return path or use other methods to detect the path further.
応答パスTLVの応答パスリターンコードが「指定された応答パスが見つかりませんでした...」に設定されたエコー応答を受信すると、出力LSRが指定どおりに一致する戻りパスを見つけられなかったことを意味します。オペレーターは、別のLSPを戻りパスとして指定するか、他の方法を使用してパスをさらに検出することを選択できます。
In some MPLS-TP deployment scenarios, IP addressing might not be available or the use of some form of non-IP encapsulation might be preferred. In such scenarios, the Non-IP encapsulation defined in [RFC6426] applies here. The LSP Ping Reply Mode in the echo request and echo reply is set to 5. The return path of the echo reply is as specified in the Reply Path TLV.
一部のMPLS-TP展開シナリオでは、IPアドレッシングが使用できない場合や、何らかの形式の非IPカプセル化の使用が優先される場合があります。このようなシナリオでは、[RFC6426]で定義されている非IPカプセル化がここに適用されます。エコー要求およびエコー応答のLSP Ping応答モードは5に設定されています。エコー応答の戻りパスは、応答パスTLVで指定されたとおりです。
Security considerations discussed in [RFC4379] apply to this document.
[RFC4379]で説明されているセキュリティの考慮事項がこのドキュメントに適用されます。
In addition, the extensions defined in this document may be used for potential "proxying" attacks. For example, an echo request initiator may specify a return path that has a destination different from that of the initiator. But normally, such attacks will not happen in an MPLS domain where the initiators and receivers belong to the same domain. Even this, in order to prevent using the extension defined in this document for proxying any possible attacks, the return path LSP should have destination to the same node where the forward path is from. The receiver may drop the echo request when it cannot determine whether the return path LSP has the destination to the initiator. That means, when sending echo request, the initiator should choose a proper source address according the specified return path LSP to help the receiver to make the decision.
さらに、このドキュメントで定義されている拡張機能は、潜在的な「プロキシ」攻撃に使用される可能性があります。たとえば、エコー要求イニシエーターは、イニシエーターとは異なる宛先を持つ戻りパスを指定できます。ただし、通常、このような攻撃は、発信側と受信側が同じドメインに属するMPLSドメインでは発生しません。これでも、このドキュメントで定義されている拡張機能を使用して攻撃をプロキシすることを防ぐために、リターンパスLSPには、フォワードパスの送信元と同じノードへの宛先が必要です。リターンパスLSPにイニシエータへの宛先があるかどうかを判断できない場合、レシーバはエコー要求をドロップすることがあります。つまり、エコー要求を送信するとき、イニシエーターは、指定されたリターンパスLSPに従って適切なソースアドレスを選択して、レシーバーが決定を行うのを助ける必要があります。
IANA has assigned the value 21 for the Reply Path TLV and assigned the value 22 for Reply TC TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs" subregistry.
IANAは、応答パスTLVに値21を割り当て、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルスイッチドパス（LSP）Pingパラメータ」レジストリの「TLVs」サブレジストリから、応答TC TLVに値22を割り当てました。
Value Meaning Reference
----- ------- ---------
21 Reply Path TLV this document (Section 4.2)
22 Reply TC TLV this document (Section 4.4)
The sub-TLV space and assignments for the Reply Path TLV will be the same as that for the Target FEC Stack TLV. Sub-types for the Target FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new sub-type added to the Target FEC Stack TLV MUST apply to the Reply Path TLV as well.
応答パスTLVのサブTLVスペースと割り当ては、ターゲットFECスタックTLVと同じになります。ターゲットFECスタックTLVと応答パスTLVのサブタイプは同じに保つ必要があります。ターゲットFECスタックTLVに追加された新しいサブタイプは、応答パスTLVにも適用する必要があります。
IANA has assigned three new sub-TLV types from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21" subregistry.
IANAは、「Multiprotocol Label Switching Architecture（MPLS）Label Switched Paths（LSPs）Ping Parameters-TLVs」レジストリ、「Sub-TLVs for TLV Type 1、16、および21」サブレジストリから3つの新しいサブTLVタイプを割り当てました。
Sub-Type Sub-TLV Name Reference
------- ----------- ---------
26 IPv4 RSVP Tunnel this document (Section 4.3.1)
27 IPv6 RSVP Tunnel this document (Section 4.3.2)
28 Static Tunnel this document (Section 4.3.3)
IANA has allocated (5 - Reply via Specified Path) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, the "Reply Modes" subregistry.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）Pingパラメータ」レジストリである「返信モード」サブレジストリから（5-指定されたパス経由の返信）を割り当てました。
Value Meaning Reference
----- ------- ----------
5 Reply via Specified Path this document (Section 4.1)
IANA has created a new subregistry for the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for Reply Path return codes.
IANAは、応答パスの戻りコード用の「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）Pingパラメータ」の新しいサブレジストリを作成しました。
This document (Section 4.2) defines the following return codes:
このドキュメント（セクション4.2）では、次の戻りコードを定義しています。
Value Meaning
------ ----------------------
0x0000 No return code
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Reserved for Experimental Use
The range of 0x0006-0xfffb is not allocated and reserved for future extensions and is allocated via Standard Action; the range of 0xfffc-0xffff is for Experimental Use.
0x0006-0xfffbの範囲は割り当てられず、将来の拡張のために予約されておらず、標準アクションを介して割り当てられます。 0xfffc-0xffffの範囲は実験用です。
The following individuals also contributed to this document:
以下の個人もこの文書に貢献しました：
Ehud Doron Orckit-Corrigent EMail: ehudd@orckit.com
Ehud Doron Orckit-Corrigent Eメール：ehudd@orckit.com
Ronen Solomon Orckit-Corrigent EMail: RonenS@orckit.com
Ronen Solomon Orckit-Corrigent Eメール：RonenS@orckit.com
Ville Hallivuori Tellabs Sinimaentie 6 C FI-02630 Espoo, Finland EMail: ville.hallivuori@tellabs.com
Ville Hallivuori Tellabs Sinimaentie 6 C FI-02630 Espoo、Finlandメール：ville.hallivuori@tellabs.com
Xinchun Guo EMail: guoxinchun@huawei.com
Chung UOメールのX：Guo Xinchun@Huawei.com
The authors would like to thank Adrian Farrel, Peter Ashwood-Smith, Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos Pignataro, and Tom Petch for their reviews, suggestions, and comments.
著者のレビュー、提案、コメントを提供してくれたAdrian Farrel、Peter Ashwood-Smith、Sriganesh Kini、Gregory Mirsky、Eric Grey、Loa Andersson、Carlos Pignataro、Tom Petchに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、2004年10月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Rekhter、Y。、およびD. Papadimitriou、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリーをサポートするRSVP-TE拡張機能」、RFC 4872、2007年5月。
[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。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、2009年2月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「要件、MPLSトランスポートプロファイル」、RFC 5654、2009年9月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
Authors' Addresses
著者のアドレス
Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China
Mach（GU O一）Chen hu Aはテクノロジー株式会社Q14 hu Aはキャンパス、第156号はiqing道路、hラブドット地区北京100095中国
EMail: mach.chen@huawei.com
Wei Cao Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China
Wei CA oh UA is Technologies co。、Ltd Q14 hu A is campus、no。156 be iblueroad、h love-dot District Beijing 100095 China
EMail: wayne.caowei@huawei.com
So Ning Tata Communications
そ にんｇ たた こっむにかちおんｓ
EMail: ning.so@tatacommunications.com
Frederic Jounay Orange CH 4 rue caudray 1020 Renens Switzerland
Frederic Jounay Orange CH 4 rue caudray 1020 Renensスイス
EMail: frederic.jounay@orange.ch
Simon Delord
サイモン・デロード
EMail: Simon.delord@team.telstra.com