[要約] RFC 7743は、ラベルスイッチパス（LSP）Pingのための中継エコーリプライメカニズムに関する要約です。このRFCの目的は、LSP Pingの効果的な実装と運用を支援することです。
Internet Engineering Task Force (IETF) J. Luo, Ed.
Request for Comments: 7743 ZTE
Updates: 4379 L. Jin, Ed.
Category: Standards Track
ISSN: 2070-1721 T. Nadeau, Ed.
Brocade
G. Swallow, Ed.
Cisco
January 2016
Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
ラベルスイッチドパス（LSP）pingのリレーエコー応答メカニズム
Abstract
概要
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.
一部のAS間（自律システム）およびRFC 4379のエリア間展開シナリオ（「ラベルスイッチドパス（LSP）PingおよびTraceroute」）では、応答するラベルスイッチングルーター（LSR）にイニシエーターへの使用可能なルートがない場合があります。また、イニシエーターに送信されたエコー応答メッセージは破棄され、偽陰性またはLSP PingおよびTracerouteの操作の完全な失敗を引き起こします。このドキュメントでは、LSP pingメカニズムの拡張機能について説明します。これにより、応答するLSRは、ルーティング可能な中間ノードのセットによってエコー応答をイニシエーターに中継できるようになります。このドキュメントはRFC 4379を更新します。
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/rfc7743.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7743で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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.
このドキュメントの発行。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Motivation ......................................................3
3. Extensions ......................................................5
3.1. Relayed Echo Reply Message .................................5
3.2. Relay Node Address Stack ...................................6
3.3. MTU Exceeded Return Code ...................................8
4. Procedures ......................................................8
4.1. Sending an Echo Request ....................................9
4.2. Receiving an Echo Request ..................................9
4.3. Originating a Relayed Echo Reply ..........................10
4.4. Relaying a Relayed Echo Reply .............................11
4.5. Sending an Echo Reply .....................................11
4.6. Sending Subsequent Echo Requests ..........................12
4.7. Impact on Traceroute ......................................12
5. LSP Ping Relayed Echo Reply Example ............................13
6. Security Considerations ........................................14
7. Backward Compatibility .........................................15
8. IANA Considerations ............................................15
8.1. MPLS Relayed Echo Reply ...................................15
8.2. Relay Node Address Stack TLV ..............................16
8.3. MTU Exceeded Return Code ..................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
Acknowledgements ..................................................17
Contributors ......................................................17
Authors' Addresses ................................................18
This document describes extensions to the Label Switched Path (LSP) Ping specified in [RFC4379] by adding a Relayed Echo Reply mechanism that could be used to report data-plane failures for inter-AS (Autonomous System) and inter-area LSPs. Without these extensions, the ping functionality provided by [RFC4379] would fail in many deployed inter-AS scenarios, since the replying Label Switching Router (LSR) in one AS may not have an available route to the initiator in the other AS. The mechanism in this document defines a new Message Type referred to as the "Relayed Echo Reply message" and a new TLV referred to as the "Relay Node Address Stack TLV".
このドキュメントでは、[RFC4379]で指定されているラベルスイッチドパス（LSP）Pingの拡張機能について説明します。これにより、AS間（自律システム）とエリア間LSPのデータプレーン障害の報告に使用できるリレーエコー応答メカニズムが追加されます。これらの拡張機能がないと、[RFC4379]が提供するping機能は、配備された多くのAS間シナリオで失敗します。このドキュメントのメカニズムでは、「リレーエコー応答メッセージ」と呼ばれる新しいメッセージタイプと、「リレーノードアドレススタックTLV」と呼ばれる新しいTLVを定義しています。
This document updates [RFC4379]; it includes updates to the Echo Request sending procedure in Section 4.3 of [RFC4379], the Echo Request receiving procedure in Section 4.4 of [RFC4379], the Echo Reply sending procedure in Section 4.5 of [RFC4379], and the Echo Reply receiving procedure in Section 4.6 of [RFC4379].
このドキュメントは[RFC4379]を更新します。 [RFC4379]のセクション4.3のエコー要求送信手順、[RFC4379]のセクション4.4のエコー要求受信手順、[RFC4379]のセクション4.5のエコー応答送信手順、および[RFC4379]のセクション4.6。
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]で説明されているように解釈されます。
LSP Ping [RFC4379] defines a mechanism to detect data-plane failures and localize faults. The mechanism specifies that the Echo Reply should be sent back to the initiator using a UDP packet with the IPv4/IPv6 destination address set to an address of the LSR that originated the Echo Request. This works in administrative domains where IP-address reachability is allowed among LSRs and every LSR is able to route back to the originating LSR. However, in practice, this is often not the case due to intra-provider routing policy, route hiding, and network address translation at Autonomous System Border Routers (ASBRs). In fact, it is almost always the case that in inter-AS scenarios, the only node in one AS to which direct routing is allowed from the other AS is the ASBR, and routing information from within one AS is not distributed into another AS.
LSP Ping [RFC4379]は、データプレーンの障害を検出し、障害を特定するメカニズムを定義しています。このメカニズムでは、IPv4 / IPv6宛先アドレスがエコー要求を発信したLSRのアドレスに設定されたUDPパケットを使用して、エコー応答をイニシエーターに送り返す必要があることを指定しています。これは、LSR間でのIPアドレスの到達可能性が許可され、すべてのLSRが元のLSRにルーティングできる管理ドメインで機能します。ただし、実際には、プロバイダー内のルーティングポリシー、ルートの非表示、および自律システム境界ルーター（ASBR）でのネットワークアドレス変換のため、これは多くの場合当てはまりません。実際、ほとんどの場合、AS間シナリオでは、1つのASで他のASからの直接ルーティングが許可されている唯一のノードがASBRであり、1つのAS内からのルーティング情報は別のASに配布されません。
Figure 1 demonstrates a case where an LSP is set up between PE1 and PE2. If PE1's IP address is not distributed to AS2, a traceroute from PE1 directed towards PE2 can result in a failure because an LSR in AS2 may not be able to send the Echo Reply message. For example, P2 cannot forward packets back to PE1 given that it is a routable IP address in AS1 but not routable in AS2. In this case, PE1 would detect a path break, as the Echo Reply messages would not be received. Then, localization of the actual fault would not be possible.
図1は、LSPがPE1とPE2の間に設定されている場合を示しています。 PE1のIPアドレスがAS2に配布されていない場合、PE2に向けられたPE1からのtracerouteは、AS2のLSRがエコー応答メッセージを送信できないために失敗する可能性があります。たとえば、AS1でルーティング可能なIPアドレスであるが、AS2ではルーティングできない場合、P2はパケットをPE1に転送できません。この場合、エコー応答メッセージが受信されないため、PE1はパスブレークを検出します。その場合、実際の障害の位置特定は不可能です。
Note that throughout the document, "routable address" means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP and BGP (or EGP) operating in the AS.
このドキュメント全体で、「ルーティング可能なアドレス」とは、ASで動作するIGPおよびBGP（またはEGP）によって交換される通常の情報を使用して、IPパケットをこのアドレスにルーティングできることを意味します。
+-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------>
<---------------------------- LSP ------------------------------>
Figure 1: Simple Inter-AS LSP Configuration
図1：単純なInter-AS LSP構成
A second example that illustrates how [RFC4379] would be insufficient would be the inter-area situation in a seamless MPLS architecture [MPLSARCH] as shown below in Figure 2. In this example, LSRs in the core network would not have an IP-reachable route to any of the access nodes (ANs). When tracing an LSP from one AN to the remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like the P2 node in the inter-AS scenario in Figure 1.
[RFC4379]がどのように不十分であるかを示す2番目の例は、図2に示すように、シームレスMPLSアーキテクチャ[MPLSARCH]のエリア間状況です。この例では、コアネットワークのLSRにはIP到達可能任意のアクセスノード（AN）にルーティングします。 LSPを1つのANからリモートANにトレースする場合、LSR1 / LSR2ノードは、図1のAS間シナリオのP2ノードのように、エコー応答も送信できません。
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route IS-IS L1 LDP IS-IS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
AGN: aggregation node
あＧん： あっｇれがちおん ので
Figure 2: Seamless MPLS Architecture
図2：シームレスなMPLSアーキテクチャ
This document describes extensions to the LSP Ping mechanism to facilitate a response from the replying LSR by defining a mechanism that uses a relay node (e.g., ASBR) to relay the message back to the initiator. Every designated or learned relay node must be reachable to the next relay node or to the initiator. Using a recursive approach, a relay node could relay the message to the next relay node until the initiator is reached.
このドキュメントでは、LSP Pingメカニズムの拡張機能について説明し、リレーノード（ASBRなど）を使用してメッセージをイニシエーターにリレーするメカニズムを定義することで、応答するLSRからの応答を容易にします。指定または学習されたすべてのリレーノードは、次のリレーノードまたはイニシエーターに到達可能である必要があります。再帰的アプローチを使用すると、リレーノードは、イニシエーターに到達するまでメッセージを次のリレーノードにリレーできます。
The LSP Ping relay mechanism in this document is defined for unicast. How to apply the LSP Ping relay mechanism in multicast is out of scope.
このドキュメントのLSP Pingリレーメカニズムは、ユニキャスト用に定義されています。マルチキャストでLSP Pingリレーメカニズムを適用する方法は範囲外です。
[RFC4379] defines two Message Types: Echo Request and Echo Reply. This document defines a new Message Type: Relayed Echo Reply. The Relayed Echo Reply message is used in place of the Echo Reply message when an LSR is replying LSR to a relay node.
[RFC4379]は、エコー要求とエコー応答の2つのメッセージタイプを定義しています。このドキュメントでは、新しいメッセージタイプとして、Relayed Echo Replyを定義しています。リレーされたエコー応答メッセージは、LSRがリレーノードにLSRを応答しているときに、エコー応答メッセージの代わりに使用されます。
A new TLV named the "Relay Node Address Stack TLV" is defined in this document to carry the IP addresses of the relay nodes for the replying LSR.
このドキュメントでは、「リレーノードアドレススタックTLV」という新しいTLVを定義して、応答するLSRのリレーノードのIPアドレスを伝送します。
In addition, the Maximum Transmission Unit (MTU) Exceeded Return Code is defined to indicate to the initiator that one or more TLVs will not be returned due to the MTU size.
また、MTUサイズが原因で1つ以上のTLVが返されないことをイニシエーターに示すために、最大伝送ユニット（MTU）超過戻りコードが定義されています。
It should be noted that this document focuses only on detecting the LSP that is set up using a uniform IP address family type. That is, all hops between the source and destination node use the same address family type for their LSP Ping control planes. This does not preclude nodes that support both IPv6 and IPv4 addresses simultaneously, but the entire path must be addressable using only one address family type. Support for mixed IPv4-only and IPv6-only is beyond the scope of this document.
このドキュメントでは、統一されたIPアドレスファミリタイプを使用して設定されたLSPの検出のみに焦点を当てていることに注意してください。つまり、送信元ノードと宛先ノード間のすべてのホップは、LSP Pingコントロールプレーンに同じアドレスファミリタイプを使用します。これは、IPv6とIPv4の両方のアドレスを同時にサポートするノードを排除するものではありませんが、パス全体が1つのアドレスファミリタイプのみを使用してアドレス可能でなければなりません。 IPv4のみとIPv6のみの混在のサポートは、このドキュメントの範囲外です。
The Relayed Echo Reply message is a UDP packet, and the UDP payload has the same format with Echo Request/Reply message. A new Message Type is requested from IANA.
リレーされたエコー応答メッセージはUDPパケットであり、UDPペイロードはエコー要求/応答メッセージと同じ形式です。新しいメッセージタイプがIANAに要求されます。
New Message Type:
Value Meaning
----- -------
5 MPLS Relayed Echo Reply
The use of TCP and UDP port number 3503 is described in [RFC4379] and has been allocated by IANA for LSP Ping messages. The Relayed Echo Reply message will use the same port number.
TCPおよびUDPポート番号3503の使用は[RFC4379]で説明されており、LSA Pingメッセージ用にIANAによって割り当てられています。リレーされたエコー応答メッセージは同じポート番号を使用します。
The Relay Node Address Stack TLV is an optional TLV. It MUST be carried in the Echo Request, Echo Reply, and Relayed Echo Reply messages if the Echo Reply relayed mechanism described in this document is required. Figure 3 illustrates the TLV format.
リレーノードアドレススタックTLVはオプションのTLVです。このドキュメントで説明されているEcho Replyリレーメカニズムが必要な場合は、Echo Request、Echo Reply、Relayed Echo Replyメッセージで伝達する必要があります。図3に、TLVフォーマットを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Offset | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Stack of Relayed Addresses ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Relay Node Address Stack TLV
図3：リレーノードアドレススタックTLV
- Type: Value is 32768. The value has been assigned by IANA from the 32768-49161 range as suggested by [RFC4379], Section 3.
- タイプ：値は32768です。この値は、[RFC4379]のセクション3で提案されているように、32768〜49161の範囲からIANAによって割り当てられています。
- Length: The length of the value field in octets.
- 長さ：オクテット単位の値フィールドの長さ。
- Initiator Source Port: The source UDP port that the initiator uses in the Echo Request message, and the port that is expected to receive the Echo Reply message.
- イニシエーターソースポート：イニシエーターがエコー要求メッセージで使用するソースUDPポート、およびエコー応答メッセージを受信すると予想されるポート。
- Reply Address Type: Address type of replying router. This value also implies the length of the address field as shown below.
- 返信アドレスタイプ：返信ルーターのアドレスタイプ。この値は、次に示すように、住所フィールドの長さも意味します。
Type# Address Type Address Length
---- ------------ ------------
0 Null 0
1 IPv4 4
2 IPv6 16
- Reserved: This field is reserved and MUST be set to zero.
- 予約済み：このフィールドは予約済みであり、ゼロに設定する必要があります。
- Source Address of Replying Router: Source IP address of the originator of Echo Reply or Relay Echo Reply message.
- 応答ルーターの送信元アドレス：エコー応答またはリレーエコー応答メッセージの発信者の送信元IPアドレス。
- Destination Address Offset: The offset in octets from the top-of-stack to the destination address entry. Each entry size has been listed in this section. Please also refer to Section 4.2 for more detail of the operation.
- 宛先アドレスオフセット：スタックの先頭から宛先アドレスエントリまでのオクテット単位のオフセット。各エントリサイズはこのセクションにリストされています。操作の詳細については、セクション4.2も参照してください。
- Number of Relayed Addresses: An integer indicating the number of relayed addresses in the stack.
- リレーされたアドレスの数：スタック内のリレーされたアドレスの数を示す整数。
- Stack of Relayed Addresses: A list of relay node address entries. This stack grows downward, with relay node addresses that are further along the LSP appearing lower down in the stack. Please refer to Section 4.2 for the relay node discovery mechanism.
- リレーアドレスのスタック：リレーノードアドレスエントリのリスト。このスタックは下向きに成長し、LSPにさらに沿ったリレーノードアドレスはスタックの下位に表示されます。リレーノードの検出メカニズムについては、セクション4.2を参照してください。
The format of each relay node address entry is as below:
各リレーノードアドレスエントリの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Relay Node Address Entry
図4：リレーノードアドレスエントリ
Type# Address Type Address Length Size of the Entry
---- ------------ ------------ -----------------
0 Null 0 4
1 IPv4 4 8
2 IPv6 16 20
Reserved: The two fields are reserved and MUST be set to zero.
予約済み：2つのフィールドは予約済みであり、ゼロに設定する必要があります。
K bit: If the K bit is set to 1, then this address stack entry MUST NOT be stripped from the Relay Node Address Stack during the processing described in Section 4.2. If the K bit is clear, the entry might be stripped according to the processing described in Section 4.2.
Kビット：Kビットが1に設定されている場合、セクション4.2で説明されている処理中に、このアドレススタックエントリをリレーノードアドレススタックから削除してはなりません（MUST NOT）。 Kビットがクリアされている場合、セクション4.2で説明されている処理に従ってエントリが削除される可能性があります。
Having the K bit set in the relay node address entry causes that entry to be preserved in the Relay Node Address Stack TLV for the entire traceroute operation. A responder node MAY set the K bit to ensure its relay node address entry remains as one of the relay nodes in the Relay Node Address Stack TLV. The address with the K bit set will always be a relay node address for the Relayed Echo Reply, see Section 4.3.
リレーノードアドレスエントリにKビットを設定すると、traceroute操作全体でそのエントリがリレーノードアドレススタックTLVに保持されます。応答ノードは、リレーノードアドレスエントリがリレーノードアドレススタックTLVのリレーノードの1つとして残るように、Kビットを設定できます（MAY）。 Kビットが設定されたアドレスは、常に、Relayed Echo Replyのリレーノードアドレスになります。セクション4.3を参照してください。
Relayed Address: This field specifies the node address: either IPv4 or IPv6.
リレーされたアドレス：このフィールドはノードアドレスを指定します：IPv4またはIPv6。
This Return Code is defined to indicate that one or more TLVs were omitted from the Echo Reply or Relayed Echo Reply message to avoid exceeding the message's effective MTU size. These TLVs MAY be included in an Errored TLV's Object with their lengths set to 0 and no value. The return sub-code MUST be set to the value that otherwise would have been sent. For more detail, please refer to Section 4.2.
この戻りコードは、メッセージの有効なMTUサイズを超えないようにするために、エコー応答または中継エコー応答メッセージから1つ以上のTLVが省略されたことを示すために定義されています。これらのTLVは、長さが0に設定され、値が設定されていないエラーTLVのオブジェクトに含まれる場合があります。戻りサブコードは、他の方法で送信されたはずの値に設定する必要があります。詳細については、セクション4.2を参照してください。
MTU Exceeded Return Code:
Value Meaning
----- -------
20 One or more TLVs not returned due to MTU size
This document updates step 7 in Section 4.4 of [RFC4379] to integrate the processing of the MTU Exceeded Return Code by adding the following text:
このドキュメントは、[RFC4379]のセクション4.4のステップ7を更新して、次のテキストを追加することにより、MTU超過戻りコードの処理を統合します。
Before sending Echo Reply, the new packet size should be checked. If Best-return-code is 3 ("Replying router is an egress for the FEC at stack depth"), or 8 ("Label switched at stack-depth"), and if the packet size exceeds MTU size, then Best-return-code is 20 ("One or more TLVs not returned due to MTU size").
エコー応答を送信する前に、新しいパケットサイズを確認する必要があります。 Best-return-codeが3（「応答ルーターはスタック深度でのFECの出力」）、または8（「スタック深度でラベルが切り替えられました」）で、パケットサイズがMTUサイズを超える場合、Best-return -codeは20です（「1つ以上のTLVがMTUサイズのために返されません」）。
To perform a ping operation, the initiator first discovers the relay nodes. Once those nodes have been discovered, the initiator includes the Relay Node Address Stack TLV into any Echo Request message. The node can then ping as normal. Note that, in some cases, the repeated lack of replies to Echo Request messages may be due to a route change that has impacted the necessary stack of relay nodes. In this case, the initiator may need to rediscover the relay nodes. The following sections describe the procedures for sending and receiving Echo Request messages with the Relay Node Address Stack TLV. These procedures can be used in traceroute mode to discover the relay nodes.
ping操作を実行するには、イニシエーターは最初にリレーノードを検出します。これらのノードが検出されると、イニシエーターはリレーノードアドレススタックTLVをエコー要求メッセージに含めます。その後、ノードは通常どおりpingを実行できます。場合によっては、エコー要求メッセージに対する繰り返しの応答がないことが、必要なリレーノードのスタックに影響を与えたルート変更が原因である可能性があることに注意してください。この場合、イニシエータはリレーノードを再検出する必要があります。次のセクションでは、リレーノードアドレススタックTLVでエコー要求メッセージを送受信する手順について説明します。これらの手順は、tracerouteモードでリレーノードを検出するために使用できます。
In addition to the procedures described in Section 4.3 of [RFC4379], a Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required. The relay function initiation is out of the scope of this document. One possible way to do this is that the operator can explicitly add an option to the ping command.
[RFC4379]のセクション4.3で説明されている手順に加えて、リレー機能が必要な場合は、エコーノードメッセージにリレーノードアドレススタックTLVを含める必要があります。リレー機能の開始は、このドキュメントの範囲外です。これを行う1つの可能な方法は、オペレーターがpingコマンドにオプションを明示的に追加できることです。
When the initiator sends the first Echo Request with a Relay Node Address Stack TLV, the TLV MUST contain the initiator address as the first entry of the stack of relayed addresses, the Destination Address Offset set to this entry, and the source address of the replying router set to null. The Initiator Source Port field MUST be set to the source UDP port. Note that the first relay node address in the stack will always be the initiator's address.
イニシエーターがリレーノードアドレススタックTLVで最初のエコー要求を送信するとき、TLVは、リレーされたアドレスのスタックの最初のエントリとしてイニシエーターアドレス、このエントリに設定された宛先アドレスオフセット、および応答の送信元アドレスを含む必要があります。ルーターがnullに設定されています。 Initiator Source Portフィールドは、ソースUDPポートに設定する必要があります。スタックの最初のリレーノードアドレスは、常にイニシエーターのアドレスになります。
When sending a subsequent Echo Request message, refer to Section 4.6.
後続のエコー要求メッセージを送信する場合は、セクション4.6を参照してください。
The Type of the Relay Node Address Stack TLV (32768) falls within the range defined in [RFC4379] as "optional TLVs" that can be silently dropped if not recognized. An LSR that does not recognize the TLV SHOULD ignore it.
リレーノードアドレススタックTLVのタイプ（32768）は、[RFC4379]で「オプションのTLV」として定義されている範囲内にあり、認識されない場合は警告なしにドロップできます。 TLVを認識しないLSRはそれを無視してください。
In addition to the processes in Section 4.4 of [RFC4379], the procedures of the Relay Node Address Stack TLV are defined here.
[RFC4379]のセクション4.4のプロセスに加えて、リレーノードアドレススタックTLVの手順がここで定義されます。
Upon receiving a Relay Node Address Stack TLV in an Echo Request message, the receiver updates the "Source Address of Replying Router". The address MUST be the same as the source IP address of Relay Echo Reply (Section 4.3) or Echo Reply message (Section 4.5) being sent.
エコー要求メッセージでリレーノードアドレススタックTLVを受信すると、受信者は「応答ルータの送信元アドレス」を更新します。このアドレスは、送信されるリレーエコー応答（セクション4.3）またはエコー応答メッセージ（セクション4.5）の送信元IPアドレスと同じである必要があります。
Those address entries with the K bit set to 1 MUST be kept in the stack. The receiver MUST check the addresses of the stack in sequence from bottom to top to find the last address in the stack with the K bit set (or the top of the stack if no K bit was found). The receiver then checks the stack beginning with this entry, proceeding towards the bottom to find the first routable address IP address. The Destination Address Offset MUST be set to this entry, which is also the resolved destination address. Address entries below the first routable IP address MUST be deleted. At least one address entry of the replying LSR MUST be added at the bottom of the stack. A second address entry (or more) MAY also be added if necessary, depending on implementation. The final address added MUST be an address that is reachable through the interface that the Echo Request message would have been forwarded to if its TTL had not expired at this node. The updated Relay Node Address Stack TLV MUST be carried in the response message.
Kビットが1に設定されているアドレスエントリは、スタックに保持する必要があります。受信者はスタックのアドレスを下から上に順にチェックして、Kビットが設定されたスタック内の最後のアドレス（またはKビットが見つからなかった場合はスタックの最上部）を見つける必要があります。次に、受信者はこのエントリで始まるスタックをチェックし、下に向かって最初のルーティング可能なアドレスのIPアドレスを見つけます。宛先アドレスオフセットは、このエントリに設定する必要があります。これは、解決された宛先アドレスでもあります。最初のルーティング可能なIPアドレスの下のアドレスエントリは削除する必要があります。応答するLSRの少なくとも1つのアドレスエントリをスタックの最下部に追加する必要があります。実装によっては、必要に応じて2番目（またはそれ以上）のアドレスエントリを追加することもできます（MAY）。追加された最終アドレスは、TTLがこのノードで期限切れになっていなかった場合にエコー要求メッセージが転送されていたであろうインターフェースを介して到達可能なアドレスでなければなりません。更新されたリレーノードアドレススタックTLVは、応答メッセージで運ばれる必要があります。
If the replying LSR is configured to hide its routable address information, the address entry added in the stack MUST be a NIL entry with Address Type set to NULL.
応答するLSRがルーティング可能なアドレス情報を隠すように構成されている場合、スタックに追加されるアドレスエントリは、アドレスタイプがNULLに設定されたNILエントリでなければなりません。
If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to reach nodes in the other domain, then the final address added SHOULD set the K bit. One example of spanning two address domains is the ASBR node.
ノードが2つのアドレス指定ドメインにまたがる場合（このメッセージに関して）、どちらかの側のノードが他のドメインのノードに到達できない場合、追加された最終アドレスはKビットを設定する必要があります（SHOULD）。 2つのアドレスドメインにまたがる1つの例は、ASBRノードです。
K bit applies in the case of a NULL address, to serve as a warning to the initiator that further Echo Request messages may not result in receiving Echo Reply messages.
Kビットは、NULLアドレスの場合に適用され、さらにエコー要求メッセージがエコー応答メッセージを受信しない可能性があることをイニシエーターに警告する役割を果たします。
If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV SHOULD be included in the Echo Reply message (i.e., other optional TLVs are excluded).
完全な応答メッセージがMTUサイズを超える場合は、リレーノードアドレススタックTLVをエコー応答メッセージに含める必要があります（つまり、他のオプションのTLVは除外されます）。
The destination address determined as described in Section 4.2 is used as the next relay node address. If the resolved next relay node address is not routable, then the sending of the Relayed Echo Reply or Echo Reply will fail.
セクション4.2で説明されているように決定された宛先アドレスは、次のリレーノードアドレスとして使用されます。解決された次のリレーノードアドレスがルーティング可能でない場合、Relayed Echo ReplyまたはEcho Replyの送信は失敗します。
If the first IP address in the Relay Node Address Stack TLV is not the next relay node address, the replying LSR SHOULD send a Relayed Echo Reply message to the next relay node. The processing of Relayed Echo Reply is the same with the procedure of the Echo Reply described in Section 4.5 of [RFC4379], except the destination IP address and the destination UDP port. The destination IP address of the Relayed Echo Reply is set to the next relay node address from the Relay Node Address Stack TLV, and both the source and destination UDP port are set to 3503. The updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Relayed Echo Reply message. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node.
リレーノードアドレススタックTLVの最初のIPアドレスが次のリレーノードアドレスでない場合、応答するLSRは、リレーされたエコー応答メッセージを次のリレーノードに送信する必要があります（SHOULD）。リレーされたエコー応答の処理は、宛先IPアドレスと宛先UDPポートを除いて、[RFC4379]のセクション4.5で説明されているエコー応答の手順と同じです。リレーエコー応答の宛先IPアドレスは、リレーノードアドレススタックTLVからの次のリレーノードアドレスに設定され、送信元および宛先UDPポートの両方が3503に設定されます。セクション4.2で説明する更新されたリレーノードアドレススタックTLVは、リレーされたエコー応答メッセージで運ばれる。返信ルーターフィールドの送信元アドレスは変更されずに保持され、IPヘッダーの送信元IPアドレスフィールドは送信ノードのアドレスに設定されます。
When the next relay node address is the first one in the address list, please refer to Section 4.5.
次のリレーノードアドレスがアドレスリストの最初のアドレスである場合は、セクション4.5を参照してください。
Upon receiving a Relayed Echo Reply message with its own address as the destination address in the IP header, the relay node MUST determine the next relay node address as described in Section 4.2, with the modification that the location of the received destination address is used instead of the bottom of stack in the algorithm. The Destination Address Offset in Relay Node Address Stack TLV will be set to the next relay node address. Note that unlike in Section 4.2, no changes are made to the Stack of Relayed Addresses.
独自のアドレスをIPヘッダーの宛先アドレスとして持つリレードエコー応答メッセージを受信すると、リレーノードは、セクション4.2で説明されているように、次のリレーノードアドレスを決定する必要があります（受信した宛先アドレスの場所が代わりに使用されるように変更）。アルゴリズムのスタックの一番下。リレーノードアドレススタックTLVの宛先アドレスオフセットは、次のリレーノードアドレスに設定されます。セクション4.2とは異なり、リレーされたアドレスのスタックは変更されないことに注意してください。
If the next relay node address is not the first one in the address list, i.e., another intermediate relay node, the relay node MUST send a Relayed Echo Reply message to the determined upstream node with the payload unchanged other than the Relay Node Address Stack TLV. The TTL SHOULD be copied from the received Relay Echo Reply and decremented by 1. The Source Address of the Replying Router field is kept unmodified and the Source IP address field of the IP header is set to an address of the sending node.
次のリレーノードアドレスがアドレスリストの最初のものではない場合、つまり別の中間リレーノードである場合、リレーノードは、決定されたアップストリームノードに、リレーノードアドレススタックTLV以外のペイロードを変更せずに、リレーエコー応答メッセージを送信する必要があります。 。 TTLは、受信したリレーエコー応答からコピーして1だけ減らす必要があります（SHOULD）。応答ルーターフィールドの送信元アドレスは変更されずに保持され、IPヘッダーの送信元IPアドレスフィールドは送信ノードのアドレスに設定されます。
When the next relay node address is the first one in the address list, please refer to Section 4.5.
次のリレーノードアドレスがアドレスリストの最初のアドレスである場合は、セクション4.5を参照してください。
The Echo Reply is sent in two cases:
エコー応答は次の2つの場合に送信されます。
1. When the replying LSR receives an Echo Request, and the first IP address in the Relay Node Address Stack TLV is the next relay node address (Section 4.3), the replying LSR would send an Echo Reply to the initiator. In addition to the procedure of the Echo Reply described in Section 4.5 of [RFC4379], the updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Echo Reply.
1. 応答するLSRがエコー要求を受信し、リレーノードアドレススタックTLVの最初のIPアドレスが次のリレーノードアドレスである場合（セクション4.3）、応答するLSRはエコー応答をイニシエーターに送信します。 [RFC4379]のセクション4.5で説明されているエコー応答の手順に加えて、セクション4.2で説明されている更新されたリレーノードアドレススタックTLVは、エコー応答で運ばれる必要があります。
If the receiver does not recognize the Relay Node Address Stack TLV, as per Sections 3 and 4.5 of [RFC4379], it will send an Echo Reply without including the TLV.
[RFC4379]のセクション3および4.5のように、受信機がリレーノードアドレススタックTLVを認識しない場合、TLVを含めずにエコー応答を送信します。
2. When the intermediate relay node receives a Relayed Echo Reply, and the first IP address in the Relay Node Address Stack TLV is the next relay node address (Section 4.4), the intermediate relay node will send the Echo Reply to the initiator, and update the Message Type field from type of "Relayed Echo Reply" to "Echo Reply". The updated Relay Node Address Stack TLV described in Section 4.4 MUST be carried in the Echo Reply. The destination IP address of the Echo Reply is set to the first IP address in the stack, and the destination UDP port will be copied from the Initiator Source Port field of the Relay Node Address Stack TLV. The source UDP port should be 3503. The TTL of the Echo Reply SHOULD be copied from the received Relay Echo Reply and decremented by 1. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node.
2.中間リレーノードがリレーエコー応答を受信し、リレーノードアドレススタックTLVの最初のIPアドレスが次のリレーノードアドレスである場合（セクション4.4）、中間リレーノードはエコー応答をイニシエーターに送信します。 Message Typeフィールドを「Relayed Echo Reply」のタイプから「Echo Reply」に更新します。セクション4.4で説明されている更新されたリレーノードアドレススタックTLVは、エコー応答で運ばれる必要があります。エコー応答の宛先IPアドレスはスタック内の最初のIPアドレスに設定され、宛先UDPポートはリレーノードアドレススタックTLVのイニシエーターソースポートフィールドからコピーされます。送信元UDPポートは3503である必要があります。エコー応答のTTLは、受信したリレーエコー応答からコピーし、1だけ減らす必要があります。応答ルーターフィールドの送信元アドレスは変更されず、IPヘッダーの送信元IPアドレスフィールドが保持されます。送信ノードのアドレスに設定されます。
During a traceroute operation, multiple Echo Request messages are sent. Each time the TTL is increased, the initiator SHOULD copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. The Relay Node Address Stack TLV MUST NOT be modified except as follows. A NIL entry that does not have the K bit set MAY be removed. A NIL entry with the K bit serves as a warning that further Echo Request messages are likely not to result in a reply. If, however, the initiator decides to continue a traceroute operation, the NIL entry with the K bit set MUST be removed. The Source Address of the Replying Router and Destination Address Offset fields may be preserved or reset since these fields are ignored in the received MPLS Echo Request.
traceroute操作中に、複数のエコー要求メッセージが送信されます。 TTLが増加するたびに、イニシエーターは、前のエコー応答で受信したリレーノードアドレススタックTLVを次のエコー要求にコピーする必要があります（SHOULD）。リレーノードアドレススタックTLVは、以下の場合を除いて変更してはなりません。 Kビットが設定されていないNILエントリは削除される場合があります。 KビットのあるNILエントリは、それ以降のエコー要求メッセージが応答しない可能性が高いという警告として機能します。ただし、イニシエーターがtraceroute操作を続行する場合は、Kビットが設定されたNILエントリを削除する必要があります。返信ルーターの送信元アドレスと宛先アドレスオフセットフィールドは、受信したMPLSエコー要求では無視されるため、保持またはリセットできます。
The Source IP address in Echo Reply and Relay Echo Reply should be the address of the node sending those packets, not the original responding node. Then the traceroute address output module will print the source IP address as below:
Echo ReplyおよびRelay Echo Replyの送信元IPアドレスは、元の応答ノードではなく、それらのパケットを送信するノードのアドレスである必要があります。次に、tracerouteアドレス出力モジュールは、次のように送信元IPアドレスを出力します。
if (Relay Node Address Stack TLV exists) {
Print the Source Address of Replying Router in
Relay Node Address Stack TLV;
} else {
Print the source IP address of Echo Reply message;
}
Considering the inter-AS scenario in Figure 5 below, AS1 and AS2 are two independent address domains. In the example, an LSP has been created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in AS2.
以下の図5のAS間シナリオを考えると、AS1とAS2は2つの独立したアドレスドメインです。この例では、PE1からPE2の間にLSPが作成されていますが、AS1のPE1はAS2のP2から到達できません。
+-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------>
<--------------------------- LSP ------------------------------->
Figure 5: Example Inter-AS LSP
図5：Inter-AS LSPの例
When performing LSP traceroute on the LSP, the first Echo Request sent by PE1 with outermost label TTL=1 contains the Relay Node Address Stack TLV with PE1's address as the first relayed address.
LSPでLSP tracerouteを実行すると、最外部ラベルTTL = 1のPE1によって送信された最初のエコー要求には、PE1のアドレスが最初の中継アドレスとしてのリレーノードアドレススタックTLVが含まれます。
After being processed by P1, P1's interface address facing ASBR1 without the K bit set will be added in the Relay Node Address Stack TLV address list following PE1's address in the Echo Reply.
P1によって処理された後、Kビットが設定されていないASBR1に面するP1のインターフェイスアドレスが、エコー応答のPE1のアドレスに続くリレーノードアドレススタックTLVアドレスリストに追加されます。
PE1 copies the Relay Node Address Stack TLV into the next Echo Request when receiving the Echo Reply.
PE1は、エコー応答を受信すると、リレーノードアドレススタックTLVを次のエコー要求にコピーします。
Upon receiving the Echo Request, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay address. Then it deletes P1's address, and adds its interface address facing ASBR2 with the K bit set. As a result, there will be PE1's address followed by ASBR1's interface address facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply sent by ASBR1.
ASBR1はエコー要求を受信すると、リレーノードアドレススタックTLVのアドレスリストをチェックし、PE1のアドレスが次のリレーアドレスであると判断します。次に、P1のアドレスを削除し、Kビットが設定されたASBR2に面するインターフェイスアドレスを追加します。その結果、ASBR1によって送信されたエコー応答のリレーノードアドレススタックTLVに、ASBR2に面するASBR1のインターフェイスアドレスが後に続くPE1のアドレスが存在します。
PE1 then sends an Echo Request with outermost label TTL=3, containing the Relay Node Address Stack TLV copied from the received Echo Reply message. Upon receiving the Echo Request message, ASBR2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR1's interface address is the next relay address in the stack TLV. ASBR2 adds its interface address facing P2 with the K bit set. Then ASBR2 sets the next relay address as the destination address of the Relayed Echo Reply and sends the Relayed Echo Reply to ASBR1.
次に、PE1は、最も外側のラベルTTL = 3のエコー要求を送信します。これには、受信したエコー応答メッセージからコピーされたリレーノードアドレススタックTLVが含まれます。エコー要求メッセージを受信すると、ASBR2はリレーノードアドレススタックTLVのアドレスリストをチェックし、ASBR1のインターフェイスアドレスがスタックTLVの次のリレーアドレスであることを確認します。 ASBR2は、Kビットが設定されたP2に面するインターフェイスアドレスを追加します。次に、ASBR2は次のリレーアドレスをリレーエコー応答の宛先アドレスとして設定し、リレーエコー応答をASBR1に送信します。
Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay node. Then ASBR1 sends an Echo Reply to PE1.
ASBR2からリレーエコー応答を受信すると、ASBR1はリレーノードアドレススタックTLVのアドレスリストをチェックし、PE1のアドレスが次のリレーノードであると判断します。次に、ASBR1はエコー応答をPE1に送信します。
For the Echo Request with outermost label TTL=4, P2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR2's interface address is the next relay address. Then P2 sends a Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV containing four addresses: PE1's, ASBR1's interface address, ASBR2's interface address, and P2's interface address facing PE2 in sequence.
最も外側のラベルがTTL = 4のエコー要求の場合、P2はリレーノードアドレススタックTLVのアドレスリストをチェックし、ASBR2のインターフェイスアドレスが次のリレーアドレスであると判断します。次に、P2は、4つのアドレス（PE1、ASBR1のインターフェースアドレス、ASBR2のインターフェースアドレス、PE2に面するP2のインターフェースアドレス）を順番に含むリレーノードアドレススタックTLVでリレーエコー応答をASBR2に送信します。
Then, according to the process described in Section 4.4, ASBR2 sends the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo Reply, ASBR1 sends an Echo Reply to PE1. And, as relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to the initiator PE1.
次に、セクション4.4で説明されているプロセスに従って、ASBR2がリレーされたエコー応答をASBR1に送信します。 ASBR1は、リレーされたエコー応答を受信すると、エコー応答をPE1に送信します。そして、ASBR2とASBR1によって中継されるように、エコー応答は最終的にイニシエーターPE1に送信されます。
For the Echo Request with outermost label TTL=5, the Echo Reply would relayed to PE1 by ASBR2 and ASBR1, similar to the case of TTL=4.
最も外側のラベルがTTL = 5のエコー要求の場合、TTL = 4の場合と同様に、エコー応答はASBR2とASBR1によってPE1にリレーされます。
The Echo Reply from the replying node that has no IP reachable route to the initiator is thus transmitted to the initiator by multiple relay nodes.
したがって、イニシエーターへのIP到達可能ルートを持たない応答ノードからのエコー応答は、複数のリレーノードによってイニシエーターに送信されます。
The Relayed Echo Reply mechanism for LSP Ping creates an increased risk of DoS by putting the IP address of a target router in the Relay Node Address Stack. These messages could then be used to attack the control plane of an LSR by overwhelming it with these packets. A rate limiter SHOULD be applied to the well-known UDP port on the relay node as suggested in [RFC4379]. The node that acts as a relay node SHOULD validate the relay reply against a set of valid source addresses and discard packets from untrusted border router addresses. An implementation SHOULD provide such filtering capabilities.
LSP Pingのリレーエコー応答メカニズムは、ターゲットルーターのIPアドレスをリレーノードアドレススタックに置くことにより、DoSのリスクを高めます。これらのメッセージは、LSRのコントロールプレーンをこれらのパケットで圧倒することによって攻撃するために使用される可能性があります。 [RFC4379]で提案されているように、中継ノードの既知のUDPポートにレートリミッターを適用する必要があります（SHOULD）。リレーノードとして機能するノードは、一連の有効な送信元アドレスに対してリレー応答を検証し、信頼されていない境界ルーターアドレスからのパケットを破棄する必要があります（SHOULD）。実装は、このようなフィルタリング機能を提供する必要があります（SHOULD）。
If an operator wants to obscure their nodes, it is RECOMMENDED that they replace the replying node address that originated the Echo Reply with the NIL address entry in the Relay Node Address Stack TLV.
オペレーターがノードを覆い隠したい場合は、エコー応答を発信した応答ノードアドレスを、リレーノードアドレススタックTLVのNILアドレスエントリに置き換えることをお勧めします。
A receiver of an MPLS Echo Request could verify that the first address in the Relay Node Address Stack TLV is the same address as the source IP address field of the received IP header.
MPLSエコー要求の受信者は、リレーノードアドレススタックTLVの最初のアドレスが、受信したIPヘッダーの送信元IPアドレスフィールドと同じアドレスであることを確認できます。
The Relay Node Address Stack TLV has the path information of the LSP, and such information may be maliciously used by any uncontrolled LSR/ LER. We have two ways to reduce the path information in the TLV:
リレーノードアドレススタックTLVにはLSPのパス情報があり、そのような情報は、制御されていないLSR / LERによって悪意を持って使用される可能性があります。 TLVのパス情報を削減する方法は2つあります。
o It is recommended to clear the K bit in the relay address entry unless it must be set (e.g., as listed in Section 4.2).
o 設定する必要がない限り、リレーアドレスエントリのKビットをクリアすることをお勧めします（たとえば、セクション4.2にリストされているように）。
o It is recommended to use the NIL address entry to hide node information, if possible.
o 可能であれば、NILアドレスエントリを使用してノード情報を非表示にすることをお勧めします。
Other security considerations discussed in [RFC4379] are also applicable to this document.
[RFC4379]で説明されている他のセキュリティの考慮事項もこのドキュメントに適用できます。
When one of the nodes along the LSP does not support the mechanism specified in this document, the node will ignore the Relay Node Address Stack TLV as described in Section 4.2. Then the initiator may not receive the Relay Node Address Stack TLV in Echo Reply message from that node. In this case, an indication should be reported to the operator, and the Relay Node Address Stack TLV in the next Echo Request message should be copied from the previous Echo Request, and continue the ping process. If the node described above is located between the initiator and the first relay node, the ping process could continue without interruption.
LSPに沿ったノードの1つがこのドキュメントで指定されたメカニズムをサポートしていない場合、セクション4.2で説明されているように、ノードはリレーノードアドレススタックTLVを無視します。次に、イニシエータは、そのノードからのエコー応答メッセージでリレーノードアドレススタックTLVを受信しない場合があります。この場合、指示がオペレーターに報告され、次のエコー要求メッセージのリレーノードアドレススタックTLVが前のエコー要求からコピーされ、pingプロセスを続行する必要があります。上記のノードがイニシエータと最初のリレーノードの間にある場合、pingプロセスは中断せずに続行できます。
IANA has assigned one new Message Type, one new TLV, and one Return Code.
IANAは、1つの新しいメッセージタイプ、1つの新しいTLV、および1つの戻りコードを割り当てました。
One new Message Type from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Message Type" subregistry has been allocated:
「Message Type」サブレジストリの「Multi-Protocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリから1つの新しいメッセージタイプが割り当てられました。
Value Meaning
----- -------
5 MPLS Relayed Echo Reply
The value has been assigned from the "Standards Action" [RFC5226] range (0-191) using the lowest free value within this range.
この値は、「標準アクション」[RFC5226]の範囲（0〜191）から、この範囲内で最も低い空き値を使用して割り当てられています。
One new TLV from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "TLVs" subregistry has been allocated:
「TLVs」サブレジストリの「Multi-Protocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリから1つの新しいTLVが割り当てられました。
Type TLV Name
---- --------
32768 Relay Node Address Stack TLV
The value has been assigned from the "Standards Action" range (32768-49161) as suggested by [RFC4379] Sections 3 and 7.2 using the first free value within this range.
[RFC4379]セクション3および7.2で提案されているように、この値は「標準アクション」の範囲（32768〜49161）から割り当てられており、この範囲内の最初の空き値を使用しています。
The MTU Exceeded return code from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Return Codes"subregistry has been allocated:
「戻りコード」サブレジストリの「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）Pingパラメータ」レジストリからのMTU超過戻りコードが割り当てられています。
Value Meaning
----- -------
20 One or more TLVs not returned due to MTU size
The value has been assigned from the "Standards Action" range (0-191) using the lowest free value within this range.
この値は、「標準アクション」の範囲（0〜191）から、この範囲内で最も低い空き値を使用して割り当てられています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、DOI 10.17487 / RFC4379、2006年2月、<http://www.rfc-editor.org / info / rfc4379>。
[MPLSARCH] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.
[MPLSARCH] Leymann、N.、Decraene、B.、Filsfils、C.、Konstantynowicz、M。、およびD. Steinberg、「シームレスMPLSアーキテクチャ」、Work in Progress、draft-ietf-mpls-seamless-mpls-07、 2014年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
Acknowledgements
謝辞
The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory Mirsky, Nobo Akiya, and Joel M. Halpern for their valuable comments and suggestions.
著者は、貴重なコメントと提案をしてくれたCarlos Pignataro、Xinwen Jiao、Manuel Paul、Loa Andersson、Wim Henderickx、Mach Chen、Thomas Morin、Gregory Mirsky、Nobo Akiya、およびJoel M. Halpernに感謝します。
Contributors
貢献者
Ryan Zheng JSPTPD 371, Zhongshan South Road Nanjing 210006 China
ライアンZ非常にGJ SPT PD 371、Z Hongshan南道路南京210006中国
Email: ryan.zhi.zheng@gmail.com
Authors' Addresses
著者のアドレス
Jian Luo (editor) ZTE 50, Ruanjian Avenue Nanjing 210012 China
J Ian luo（編集者）ZT E 50、RuボタンアベニューNaN京210012中国
Email: luo.jian@zte.com.cn
Lizhong Jin (editor) Shanghai China
l i kind of jin（editor）Shanghai China
Email: lizho.jin@gmail.com
Thomas Nadeau (editor) Brocade
Thomas Nadeau（編集者）Brocade
Email: tnadeau@lucidvision.com
George Swallow (editor) Cisco Systems
George Swallow（編集者）Cisco Systems
Email: swallow@cisco.com