[要約] RFC 7555は、MPLSネットワークでのエコーリクエストをプロキシするための仕様です。目的は、MPLSネットワーク内のエンドツーエンドの可用性を監視するために、エコーリクエストをプロキシすることです。
Internet Engineering Task Force (IETF) G. Swallow
Request for Comments: 7555 V. Lim
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Aldrin
Huawei Technologies
June 2015
Proxy MPLS Echo Request
プロキシMPLSエコー要求
Abstract
概要
This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).
このドキュメントでは、ラベルスイッチドパスでマルチプロトコルラベルスイッチドプロトコル（MPLS）pingをリモートで開始する方法を定義します。 MPLSプロキシping要求は、ラベルスイッチドパスに沿ってラベルスイッチングルータに送信されます。この機能の主な動機は、最初に大規模なポイントツーマルチポイント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/rfc7555.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7555で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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
1.1. Requirements Language ......................................4
1.2. Terminology ................................................5
2. Proxy Ping Overview .............................................5
2.1. Initiating Proxy Ping ......................................6
2.2. Handling at Proxy LSR ......................................6
2.2.1. Backward Compatibility ..............................6
3. Proxy MPLS Echo Request/Reply Procedures ........................7
3.1. Procedures for the Initiator ...............................7
3.2. Procedures for the Proxy LSR ...............................9
3.2.1. Proxy LSR Handling When It Is Egress for FEC .......11
3.2.2. Downstream Detailed Maps and Downstream
Maps in Proxy Reply ................................12
3.2.3. Sending an MPLS Proxy Ping Reply ...................12
3.2.4. Sending the MPLS Echo Requests .....................13
3.2.4.1. Forming the Base MPLS Echo Request ........13
3.2.4.2. Per-Interface Sending Procedures ..........14
4. Proxy Ping Request/Reply Messages ..............................15
4.1. Proxy Ping Request/Reply Message Formats ..................15
4.2. Proxy Ping Request Message Contents .......................15
4.3. Proxy Ping Reply Message Contents .........................16
5. TLV Formats ....................................................16
5.1. Proxy Echo Parameters TLV .................................16
5.1.1. Next Hop Sub-TLV ...................................20
5.2. Reply-to Address TLV ......................................21
5.3. Upstream Neighbor Address TLV .............................21
5.4. Downstream Neighbor Address TLV ...........................22
6. Security Considerations ........................................23
7. IANA Considerations ............................................24
7.1. Proxy Echo Parameters Sub-TLVs ............................24
7.2. Proxy Flags ...............................................25
7.3. Downstream Address Mapping Registry .......................25
7.4. Next Hop Sub-TLV Address Type Registry ....................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Acknowledgements ..................................................27
Authors' Addresses ................................................28
This document is motivated by two broad issues in connection with diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). The first is scalability due to the automatic replication of Multiprotocol Label Switching (MPLS) Echo Request messages as they proceed down the tree. The second, which is primarily motivated by LDP-based P2MP and Multipoint-to-Multipoint (MP2MP) LSPs [RFC6388], is the ability to trace a sub-LSP from leaf node to root node.
このドキュメントは、ポイントツーマルチポイント（P2MP）ラベルスイッチドパス（LSP）の診断に関連する2つの広範な問題を動機としています。 1つ目は、マルチプロトコルラベルスイッチング（MPLS）エコー要求メッセージがツリーを下っていくときに自動的に複製されるため、スケーラビリティです。 2つ目は、主にLDPベースのP2MPおよびマルチポイントツーマルチポイント（MP2MP）LSP [RFC6388]によって動機付けられており、リーフノードからルートノードまでサブLSPをトレースする機能です。
When tracing from a source to a particular leaf in a P2MP or MP2MP tree, nodes not along that path will need to process MPLS Echo Request messages that are received. The number of MPLS Echo Replies sent in response to an MPLS Echo Request quickly multiplies, as the Label Switching Routers (LSRs), which are part of the tree but not along the path of the trace, could be responding to the received MPLS Echo Request as well. This could also overwhelm the source to process all the MPLS Echo Reply messages it receives. It is anticipated that many of the applications for P2MP/MP2MP tunnels will require OAM that is both rigorous and scalable.
ソースからP2MPまたはMP2MPツリーの特定のリーフまでトレースする場合、そのパスに沿っていないノードは、受信したMPLSエコー要求メッセージを処理する必要があります。ツリーの一部であるがトレースのパスに沿っていないラベルスイッチングルーター（LSR）が受信したMPLSエコー要求に応答している可能性があるため、MPLSエコー要求への応答として送信されたMPLSエコー応答の数がすぐに増加します。同じように。これは、ソースを圧倒して、受信したすべてのMPLSエコー応答メッセージを処理することもできます。 P2MP / MP2MPトンネルのアプリケーションの多くは、厳密でスケーラブルなOAMを必要とすることが予想されます。
Suppose one wishes to trace a P2MP LSP to localize a fault that is affecting one egress or a set of egresses. Suppose one follows the normal procedure for tracing -- namely, repeatedly pinging from the root, incrementing the Time to Live (TTL) by one after each three or so pings. Such a procedure has the potential for producing a large amount of processing at the P2MP-LSP midpoints and egresses. It also could produce an unwieldy number of replies back to the root.
P2MP LSPをトレースして、1つの出力または一連の出力に影響を与えている障害を特定したいとします。トレースの通常の手順、つまりルートから繰り返しpingを実行し、pingを3回実行するたびにTime to Live（TTL）を1ずつ増加させるとします。このような手順は、P2MP-LSPの中間点と出口で大量の処理を生成する可能性があります。また、ルートへの返信が手に負えないほど多くなる可能性があります。
One alternative would be to begin sending pings from points at or near the affected egress(es) and then work backwards toward the root. The TTL could be held constant (say, two), limiting the number of responses to the number of next-next-hops of the point where a ping is initiated.
1つの代替策は、影響を受ける出口またはその近くのポイントからpingの送信を開始し、ルートに向かって逆方向に動作することです。 TTLは一定（たとえば、2）に保つことができ、pingが開始されるポイントの次のネクストホップの数に応答の数を制限します。
In the case of Resource Reservation Protocol Traffic Engineering (RSVP-TE), all setup is initiated from the root of the tree. Thus, the root of the tree has knowledge of all the leaf nodes and usually the topology of the entire tree. Thus, the above alternative can easily be initiated by the root node.
リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）の場合、すべてのセットアップはツリーのルートから開始されます。したがって、ツリーのルートには、すべてのリーフノードと、通常はツリー全体のトポロジに関する知識があります。したがって、上記の代替案はルートノードによって簡単に開始できます。
In [RFC6388], the situation is quite different. Leaf nodes initiate connectivity to the tree, which is granted by the first node toward the root that is part of the tree. The root node may only be aware of the immediately adjacent (downstream) nodes of the tree. Initially, the leaf node only has knowledge of the (upstream) node to which it is immediately adjacent. However, this is sufficient information to initiate a trace. First, the above procedure is applied by asking that node to ping across the final link. That is, a message is sent from the leaf to the upstream node requesting it to send an MPLS Echo Request for the Forward Equivalence Class (FEC) of the tree in question on said link. The leaf node also requests the identity of the upstream neighbor's upstream neighbor for that FEC. With this information, the procedure can iteratively be applied until the fault is localized or the root node is reached. In all cases, the TTL for the request need only be at most 2. Thus, the processing load of each request is small, since only a limited number of nodes will receive the request.
[RFC6388]では、状況はかなり異なります。リーフノードはツリーへの接続を開始します。これは、ツリーの一部であるルートへの最初のノードによって許可されます。ルートノードは、ツリーのすぐ隣の（下流の）ノードのみを認識します。最初は、リーフノードは、それが直接隣接している（上流の）ノードの知識しか持っていません。ただし、これはトレースを開始するには十分な情報です。最初に、上記の手順は、そのノードに最終リンクを介してpingするように要求することによって適用されます。つまり、メッセージがリーフから上流ノードに送信され、当該リンク上の問題のツリーの転送等価クラス（FEC）のMPLSエコー要求を送信するように要求します。リーフノードは、そのFECのアップストリームネイバーのアップストリームネイバーのIDも要求します。この情報を使用して、障害が局所化されるかルートノードに到達するまで、手順を繰り返し適用できます。すべての場合において、要求のTTLは最大2で十分です。したがって、限られた数のノードのみが要求を受信するため、各要求の処理負荷は小さくなります。
This document defines protocol extensions to MPLS ping [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down an LSP or part of an LSP. The procedure described in the paragraphs above does require that the initiator know the previous-hop node to the one which was pinged on the prior iteration. This information is readily available in [RFC4875]. This document also provides a means for obtaining this information for P2MP and MP2MP LSPs that are set up with LDP as described in [RFC6388].
このドキュメントでは、MPLS ping [RFC4379]のプロトコル拡張を定義して、サードパーティがMPLSエコー要求メッセージをリモートでLSPまたはLSPの一部に送信できるようにします。上記の段落で説明した手順では、イニシエーターが、前の反復でpingされたノードの前のホップノードを知っている必要があります。この情報は、[RFC4875]ですぐに利用できます。このドキュメントは、[RFC6388]で説明されているように、LDPで設定されたP2MPおよびMP2MP LSPのこの情報を取得する手段も提供します。
While the motivation for this document came from multicast scaling concerns, its applicability may be wider. The procedures presented in this document are applicable to all LSP Ping FEC types where the MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply can be sent out of band of the LSP over IP. Remote pinging of LSPs that involves the use of in-band control channels is beyond the scope of this document.
このドキュメントの動機はマルチキャストスケーリングの懸念から来ましたが、その適用範囲はより広い可能性があります。このドキュメントで説明する手順は、MPLSエコー要求/応答がIPカプセル化され、MPLSエコー応答がLSP over IPの帯域外に送信できるすべてのLSP Ping FECタイプに適用できます。インバンド制御チャネルの使用を含むLSPのリモートpingは、このドキュメントの範囲外です。
Other uses of this facility are beyond the scope of this document. In particular, the procedures defined in this document only allow testing of a FEC stack consisting of a single FEC. The procedures also do not allow the initiator to specify the label assigned to that FEC, nor do the procedures allow the initiator to cause any additional labels to be added to the label stack of the actual MPLS Echo Request message.
この機能の他の使用法は、このドキュメントの範囲外です。特に、このドキュメントで定義されている手順は、単一のFECで構成されるFECスタックのテストのみを許可します。また、この手順では、イニシエーターがそのFECに割り当てられたラベルを指定することも、イニシエーターが実際のMPLSエコー要求メッセージのラベルスタックに追加のラベルを追加することもできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The term "Must Be Zero" (MBZ) is used in TLV descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
「ゼロでなければならない」（MBZ）という用語は、予約済みフィールドのTLV記述で使用されます。これらのフィールドは送信時にゼロに設定し、受信時に無視する必要があります。
Based on context, the terms "leaf" and "egress" are used interchangeably. "Egress" is used where consistency with [RFC4379] was deemed appropriate. "Receiver" is used in the context of receiving protocol messages.
コンテキストに基づいて、「リーフ」と「出口」という用語は互換的に使用されます。 [Egress]は、[RFC4379]との整合性が適切であると見なされた場合に使用されます。 「Receiver」は、プロトコルメッセージを受信する状況で使用されます。
Term Definition
----- -------------------------------------------
LSP Label Switched Path
LSR Label Switching Router
mLDP Multipoint LDP
MP2MP Multipoint to Multipoint
MTU Maximum Transmission Unit
P2MP Point to Multipoint
TTL Time to Live
This document defines a protocol interaction between a first LSR and another LSR that is part of an LSP in order to allow the first LSR to request that the second LSR initiate an LSP Ping for the LSP on the first LSR's behalf. Since the second LSR sends the LSP Ping on behalf of the first LSR, it does not maintain state to be able to handle the corresponding LSP Ping response. Instead, the responder to the LSP Ping sends the LSP Ping response to either the first LSR or another LSR configured to handle it. Two new LSP Ping messages are defined for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply.
このドキュメントでは、最初のLSRが最初のLSRに代わってLSPのLSP Pingを開始することを最初のLSRが要求できるようにするために、最初のLSRとLSPの一部である別のLSR間のプロトコル相互作用を定義します。 2番目のLSRは最初のLSRの代わりにLSP Pingを送信するため、対応するLSP Ping応答を処理できる状態を維持しません。代わりに、LSP Pingへの応答側は、LSP Ping応答を最初のLSRまたはそれを処理するように構成された別のLSRに送信します。リモートping用に2つの新しいLSP Pingメッセージが定義されています。MPLSプロキシPing要求とMPLSプロキシPing応答です。
A remote ping operation on a P2MP LSP generally involves at least three LSRs; in some scenarios, none of these are the ingress (root) or an egress (leaf) of the LSP.
P2MP LSPでのリモートping操作には、通常、少なくとも3つのLSRが含まれます。一部のシナリオでは、これらのいずれもLSPの入力（ルート）または出力（リーフ）ではありません。
We refer to these LSRs with the following terms:
これらのLSRを以下の用語で参照します。
Initiator - the LSR that initiates the ping operation by sending an MPLS Proxy Ping Request message
イニシエーター-MPLSプロキシping要求メッセージを送信してping操作を開始するLSR
Proxy LSR - the LSR that is the destination of the MPLS Proxy Ping Request message and the potential initiator of the MPLS Echo Request
プロキシLSR-MPLSプロキシPingリクエストメッセージの宛先であり、MPLSエコーリクエストの潜在的なイニシエーターであるLSR
Receiver(s) - the LSR(s) that receive the MPLS Echo Request message
レシーバー-MPLSエコー要求メッセージを受信するLSR
Responder - A receiver that responds to an MPLS Proxy Ping Request or an MPLS Echo Request
レスポンダ-MPLSプロキシPing要求またはMPLSエコー要求に応答するレシーバ
We note that in some scenarios, the initiator could also be the responder; in that case, the response would be internal to the LSR.
一部のシナリオでは、イニシエーターがレスポンダーになることもあります。その場合、応答はLSRの内部になります。
The initiator formats an MPLS Proxy Ping Request message and sends it to the Proxy LSR, an LSR it believes to be on the path of the LSP. This message instructs the Proxy LSR either to reply with Proxy information or to send an MPLS Echo Request in-band of the LSP. The initiator requests Proxy information so that it can learn additional information it needs to use to form a subsequent MPLS Proxy Ping Request. For example, during LSP traceroute, an initiator needs the downstream map information to form an MPLS Echo Request. An initiator may also want to learn a Proxy LSR's FEC neighbor information so that it can form Proxy Ping Requests to various LSRs along the LSP.
イニシエーターは、MPLSプロキシping要求メッセージをフォーマットし、LSPのパス上にあると考えられるLSRであるプロキシLSRに送信します。このメッセージは、プロキシLSRに、プロキシ情報で応答するか、LSPのインバンドでMPLSエコー要求を送信するように指示します。イニシエーターは、後続のMPLSプロキシping要求を形成するために使用する必要がある追加情報を学習できるように、プロキシ情報を要求します。たとえば、LSP tracerouteの間、イニシエーターはMPLSエコー要求を形成するためにダウンストリームマップ情報を必要とします。イニシエーターは、LSPに沿ってさまざまなLSRへのプロキシPing要求を形成できるように、プロキシLSRのFECネイバー情報を学習することもできます。
The Proxy LSR either replies with the requested Proxy information or validates that it has a label mapping for the specified FEC and that it is authorized to send the specified MPLS Echo Request on behalf of the initiator.
プロキシLSRは、要求されたプロキシ情報で応答するか、指定されたFECのラベルマッピングがあり、イニシエーターの代わりに指定されたMPLSエコー要求を送信する権限があることを検証します。
If the Proxy LSR has a label mapping for the FEC and all authorization checks have passed, the Proxy LSR formats an MPLS Echo Request. If the source address of the MPLS Echo Request is not set to the Proxy Request source address, the initiator MUST include a Reply-to Address TLV containing the source address to use in the MPLS Echo Request. It then sends the MPLS Echo Request in-band of the LSP.
プロキシLSRにFECのラベルマッピングがあり、すべての許可チェックに合格した場合、プロキシLSRはMPLSエコー要求をフォーマットします。 MPLSエコー要求のソースアドレスがプロキシ要求ソースアドレスに設定されていない場合、イニシエーターは、MPLSエコー要求で使用するソースアドレスを含む返信先アドレスTLVを含める必要があります。次に、LSPのインバンドでMPLSエコー要求を送信します。
The receivers process the MPLS Echo Request as normal, sending their MPLS Echo Replies back to the initiator.
レシーバーはMPLSエコー要求を通常どおり処理し、MPLSエコー応答をイニシエーターに送り返します。
If the Proxy LSR failed to send an MPLS Echo Request as normal because it encountered an issue while attempting to send, an MPLS Proxy Ping Reply message is sent back with a Return Code indicating that the MPLS Echo Request could not be sent.
送信しようとしたときに問題が発生したために、プロキシLSRが通常どおりMPLSエコー要求を送信できなかった場合、MPLSエコー要求が送信できなかったことを示す戻りコードとともにMPLSプロキシPing応答メッセージが返送されます。
As described in Section 4.4 of [RFC4379], if the packet is not well-formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set to "Malformed echo request received" and the Return Subcode to zero. If there are any TLVs not marked as "Ignore" that the Proxy LSR does not understand, the Proxy LSR SHOULD send an MPLS "TLV not understood" (as appropriate), and the Return Subcode is set to zero.
[RFC4379]のセクション4.4で説明されているように、パケットの形式が適切でない場合、LSR Xは、戻りコードを「不正なエコー要求を受信しました」に設定し、戻りサブコードをゼロにしてMPLSエコー応答を送信する必要があります。プロキシLSRが理解できない「無視」としてマークされていないTLVがある場合、プロキシLSRはMPLSを送信する必要があります（必要に応じて）「TLVが理解できません」、およびリターンサブコードはゼロに設定されます。
In the case where the targeted Proxy LSR does not understand the LSP Ping Echo Request at all, like any other LSR that does not understand the messages, it MUST drop the message and MUST NOT send any message back to the initiator.
ターゲットのプロキシLSRが、メッセージを理解しない他のLSRと同様に、LSP Pingエコー要求をまったく理解しない場合、メッセージをドロップし、イニシエーターにメッセージを返してはなりません（MUST）。
The initiator creates an MPLS Proxy Ping request message.
イニシエータは、MPLSプロキシPing要求メッセージを作成します。
The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the target FEC stack is used at the Proxy LSR to look up the MPLS label stack that will be used to encapsulate the MPLS Echo Request packet.
メッセージには、テストされているFECを説明するターゲットFECスタックが含まれている必要があります。ターゲットFECスタックの最上位のFECは、プロキシLSRで使用され、MPLSエコー要求パケットのカプセル化に使用されるMPLSラベルスタックを検索します。
The MPLS Proxy Ping Request message MUST contain a Proxy Echo Parameters TLV. In that TLV, the address type is set to either IPv4 or IPv6. The Destination IP Address is set to the value to be used by the Proxy LSR to build the MPLS Echo Request packet. The MPLS Echo Request IP header destination address is as specified in [RFC4379]. If the Address Type is IPv4, it MUST be an address is from the range 127/8; if the Address Type is IPv6, MUST be an address from the range ::ffff:7f00:0/104.
MPLSプロキシping要求メッセージには、プロキシエコーパラメータTLVが含まれている必要があります。そのTLVでは、アドレスタイプはIPv4またはIPv6に設定されます。宛先IPアドレスは、MPLSエコー要求パケットを構築するためにプロキシLSRが使用する値に設定されます。 MPLSエコー要求IPヘッダーの宛先アドレスは、[RFC4379]で指定されています。アドレスタイプがIPv4の場合、127/8の範囲のアドレスである必要があります。アドレスタイプがIPv6の場合は、:: ffff：7f00：0/104の範囲のアドレスである必要があります。
The Reply Mode and Global Flags of the Proxy Echo Parameters TLV are set to the values to be used in the MPLS Echo Request message header. The Source UDP Port is set to the value to be used in the MPLS Echo Request (the source port is supplied by the Proxy Ping initiator because it or an LSR known to it handles the LSP Ping responses). The TTL is set to the value to be used in the outgoing MPLS label stack. See Section 5.1 for further details.
プロキシエコーパラメータTLVの応答モードとグローバルフラグは、MPLSエコー要求メッセージヘッダーで使用される値に設定されます。送信元UDPポートは、MPLSエコー要求で使用される値に設定されます（送信元ポートは、それが認識しているLSRまたはLSRがLSP Ping応答を処理するため、プロキシPingイニシエーターによって提供されます）。 TTLは、発信MPLSラベルスタックで使用される値に設定されます。詳細については、セクション5.1を参照してください。
If the FEC's Upstream/Downstream Neighbor address information is required, the initiator sets the "Request for FEC neighbor information" Proxy Flags in the Proxy Echo Parameters TLV.
FECのアップストリーム/ダウンストリームネイバーアドレス情報が必要な場合、イニシエーターはプロキシエコーパラメーターTLVで「FECネイバー情報の要求」プロキシフラグを設定します。
If a Downstream Detailed Mapping TLV (or Downstream Mapping TLV, which is deprecated) is required in an MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream Detailed Mapping" (or "Request for Downstream Mapping") Proxy Flag in the Proxy Echo Parameters TLV. Only one of the two flags can be set.
MPLSプロキシPing応答でダウンストリーム詳細マッピングTLV（または非推奨のダウンストリームマッピングTLV）が必要な場合、イニシエーターはプロキシに「ダウンストリーム詳細マッピングの要求」（または「ダウンストリームマッピングの要求」）プロキシフラグを設定します。エコーパラメータTLV。 2つのフラグのうち1つだけを設定できます。
The Proxy Request Reply Mode is set with one of the Reply Modes defined in [RFC4379] as appropriate.
プロキシ要求応答モードは、[RFC4379]で適切に定義された応答モードの1つで設定されます。
A list of next-hop IP addresses MAY be included to limit the next hops towards which the MPLS Echo Request message will be sent. These are encoded as Next Hop sub-TLVs and included in the Proxy Echo Parameters TLV.
ネクストホップIPアドレスのリストを含めて、MPLSエコー要求メッセージが送信されるネクストホップを制限することができます。これらはNext HopサブTLVとしてエンコードされ、Proxy Echo Parameters TLVに含まれています。
Although not explicitly spelled out in [RFC4379], LSP Ping packets can be formed to a desired size using a Pad TLV and then used to test the Maximum Transmission Unit (MTU) of an LSP. When testing an LSP's MTU, if the message is transported as an IP datagram, the IP header DF bit MUST be set to prevent IP fragmentation by the IP forwarding layer. The Proxy Echo Parameter TLV MPLS Payload Size field is defined for this purpose and may be set to request that the MPLS Echo Request (including any IP and UDP header) be zero-padded to the specified size. When a non-zero MPLS payload size is specified, the Proxy LSR introduces a Pad TLV to build the MPLS Echo Request packet, so in this case, the Proxy Ping Request MUST NOT include a Pad TLV.
[RFC4379]で明示的に記述されていませんが、LSP Pingパケットは、パッドTLVを使用して目的のサイズに形成し、LSPの最大伝送ユニット（MTU）のテストに使用できます。 LSPのMTUをテストするとき、メッセージがIPデータグラムとして転送される場合、IP転送レイヤーによるIP断片化を防ぐために、IPヘッダーDFビットを設定する必要があります。プロキシエコーパラメータのTLV MPLSペイロードサイズフィールドはこの目的で定義され、MPLSエコー要求（IPおよびUDPヘッダーを含む）に指定されたサイズにゼロを埋め込むことを要求するように設定できます。ゼロ以外のMPLSペイロードサイズが指定されている場合、プロキシLSRはMPLSエコー要求パケットを構築するためにパッドTLVを導入するため、この場合、プロキシPing要求にパッドTLVを含めてはなりません（MUST NOT）。
Any of following TLVs MAY be included. These TLVs are used to form the MPLS Echo Request messages by the Proxy LSR:
以下のTLVのいずれかが含まれる場合があります。これらのTLVは、プロキシLSRによってMPLSエコー要求メッセージを形成するために使用されます。
Pad
パッド
Vendor Enterprise Number
ベンダー企業番号
Reply TOS Byte
返信TOSバイト
P2MP Responder Identifier [RFC6425]
P2MPレスポンダー識別子[RFC6425]
Echo Jitter [RFC6425]
エコージッタ[RFC6425]
Vendor Private TLVs
ベンダーのプライベートTLV
Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) TLVs MAY be included. These TLVs will be matched to the next-hop address for inclusion in those particular MPLS Echo Request messages.
ダウンストリーム詳細マッピング（DDMAP）またはダウンストリームマッピング（DSMAP）TLVが含まれる場合があります。これらのTLVは、特定のMPLSエコー要求メッセージに含めるために、ネクストホップアドレスと照合されます。
The message is then encapsulated in a UDP packet. The source UDP port for the MPLS Proxy Ping Request message is chosen by the initiator; the destination UDP port is set to 3503. The IP header is set as follows: the source IP address is a routable address of the initiator; the destination IP address is a routable address to the Proxy LSR. The packet is then sent with the IP TTL set to 255.
次に、メッセージはUDPパケットにカプセル化されます。 MPLSプロキシping要求メッセージのソースUDPポートは、イニシエーターによって選択されます。宛先UDPポートは3503に設定されます。IPヘッダーは次のように設定されます。送信元IPアドレスはイニシエーターのルーティング可能なアドレスです。宛先IPアドレスは、プロキシLSRへのルーティング可能なアドレスです。次に、パケットはIP TTLが255に設定されて送信されます。
A Proxy LSR that receives an MPLS Proxy Ping Request message parses the packet to ensure that it is a well-formed packet. It checks that the TLVs that are not marked "Ignore" are understood. If any part of the message is malformed, it sets the Return Code to "Malformed echo request received". If all the TLVs are well-formed and any TLVs are not understood, the Return Code is set to "TLV not understood". The Return Subcode is set to zero for both cases.
MPLSプロキシPing要求メッセージを受信するプロキシLSRは、パケットを解析して、それが整形式のパケットであることを確認します。 「無視」とマークされていないTLVが理解されていることを確認します。メッセージの一部が不正な形式である場合、戻りコードを「不正な形式のエコー要求を受信しました」に設定します。すべてのTLVが整形式であり、TLVが理解されていない場合、戻りコードは「TLV未理解」に設定されます。どちらの場合も、リターンサブコードはゼロに設定されます。
If the Reply Mode of the message header is not 1 ("Do not reply"), an MPLS Proxy Ping Reply message SHOULD be sent as described below.
メッセージヘッダーの返信モードが1でない場合（「返信しない」）、MPLSプロキシPing返信メッセージを以下のように送信する必要があります（SHOULD）。
If the Return Code is "TLV not understood", no more processing of the MPLS Proxy Ping Request message is required. The Proxy LSR sends an MPLS Proxy Ping Reply message with an Errored TLVs TLV containing (only) the TLVs that were not understood.
戻りコードが「TLVが理解されていません」である場合、MPLSプロキシPing要求メッセージのこれ以上の処理は必要ありません。プロキシLSRは、理解されなかったTLV（のみ）を含むエラーTLV TLVを含むMPLSプロキシPing応答メッセージを送信します。
The MPLS Proxy Ping Request is expected to be transported to the Proxy LSR via IP forwarding mechanisms instead of using the same techniques that are employed to inject an MPLS Echo Request packet into an LSP. The MPLS Echo Request would use IP TTL, MPLS TTL, and/or loopback addresses (IPv4 127.x.x.x or IPv6 ::ffff:7f00/104) in the IP header destination address field to trigger the packet to be handled via an LSR's forwarding exception processing path. The Proxy LSR MUST check whether or not MPLS Proxy Ping Request packets arrive via exception path. Packets arriving via IP TTL expiry, IP destination address set to a loopback address, or label TTL expiry MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping Reply message MAY be sent with a Return Code of 16, "Proxy Ping not authorized".
MPLSプロキシPing要求は、MPLSエコー要求パケットをLSPに挿入するために採用されているのと同じ手法を使用する代わりに、IP転送メカニズムを介してプロキシLSRに転送されることが期待されています。 MPLSエコー要求は、IPヘッダー宛先アドレスフィールドでIP TTL、MPLS TTL、ループバックアドレス（IPv4 127.xxxまたはIPv6 :: ffff：7f00 / 104）を使用して、LSRの転送を介して処理されるパケットをトリガーします例外処理パス。プロキシLSRは、MPLSプロキシPing要求パケットが例外パス経由で到着するかどうかを確認する必要があります。 IP TTL期限切れ、ループバックアドレスに設定されたIP宛先アドレス、またはラベルTTL期限切れを介して到着するパケットは、「無許可」パケットとして扱われる必要があります。 MPLSプロキシPing応答メッセージは、戻りコード16、「プロキシPingは許可されていません」で送信される場合があります。
The header fields Sender's Handle and Sequence Number are not examined, but they are included in the MPLS Proxy Ping Reply or MPLS Echo Request message, if either is sent as a direct result of the received message.
ヘッダーフィールドSender's HandleおよびSequence Numberは検査されませんが、受信メッセージの直接の結果として送信される場合、これらはMPLS Proxy Ping ReplyまたはMPLS Echo Requestメッセージに含まれます。
The Proxy LSR validates that it has a label mapping for the specified FEC, determines if it is an ingress, egress, transit or bud node, and then sets the Return Code as appropriate. A new Return Code of 19, "Replying router has FEC mapping for topmost FEC", has been defined for the case where the Proxy LSR is an ingress (for example, the head of the TE tunnel or a transit router) because the existing Return Codes defined by RFC 4379 don't match the situation. For example, when a Proxy LSR is a transit router, it's not appropriate for the Return Code to describe how the packet would transit because the MPLS Proxy Ping Request doesn't contain information about what input interface the MPLS Echo Request would be switched from at the Proxy LSR.
プロキシLSRは、指定されたFECのラベルマッピングがあることを検証し、それが入力、出力、トランジット、またはバッドノードであるかどうかを判断し、必要に応じてリターンコードを設定します。新しい戻りコード19である「応答ルータには最上位のFECのFECマッピングがあります」は、既存のReturnによりRFC 4379で定義されたコードは、状況と一致しません。たとえば、プロキシLSRが中継ルーターである場合、MPLSプロキシPing要求には、MPLSエコー要求がどの入力インターフェイスから切り替えられるかに関する情報が含まれていないため、パケットがどのように通過するかをリターンコードで説明することは適切ではありません。プロキシLSR。
The Proxy LSR then determines if it is authorized to send the specified MPLS Echo Request on behalf of the initiator. A Proxy LSR MUST be capable of filtering addresses to validate initiators. Other filters on FECs or MPLS Echo Request contents MAY be applied. If a configured filter has been invoked and an address does not pass the filter, then an MPLS Echo Request message MUST NOT be sent, and the event SHOULD be logged. An MPLS Proxy Ping Reply message MAY be sent with a Return Code of 16, "Proxy Ping not authorized".
次に、プロキシLSRは、イニシエーターに代わって、指定されたMPLSエコー要求を送信する権限があるかどうかを判断します。プロキシLSRは、イニシエーターを検証するためにアドレスをフィルタリングできる必要があります。 FECまたはMPLSエコー要求の内容に他のフィルターを適用できます。構成されたフィルターが呼び出され、アドレスがフィルターを通過しない場合、MPLSエコー要求メッセージを送信してはならず（MUST NOT）、イベントをログに記録する必要があります（SHOULD）。 MPLSプロキシPing応答メッセージは、戻りコード16、「プロキシPingは許可されていません」で送信される場合があります。
The destination address specified in the Proxy Echo Parameters TLV is checked to ensure that it conforms to the allowed IPv4 or IPv6 address range. If not, the Return Code is set to "Malformed echo request received" and the Return Subcode is set to zero. If the Reply Mode of the message header is not 1, an MPLS Proxy Ping Reply message SHOULD be sent as described below.
プロキシエコーパラメータTLVで指定された宛先アドレスがチェックされ、許可されたIPv4またはIPv6アドレス範囲に準拠していることが確認されます。そうでない場合、戻りコードは「不正なエコー要求の受信」に設定され、戻りサブコードはゼロに設定されます。メッセージヘッダーの応答モードが1でない場合は、MPLSプロキシPing応答メッセージを以下のように送信する必要があります（SHOULD）。
The TTL specified in the Proxy Echo Parameters TLV is checked to ensure it contains a value in the range [1,255]. If not, the Return Code MUST be set to 17, "Proxy Ping parameters need to be modified". If the Reply Mode of the message header is not 1, an MPLS Proxy Ping Reply message SHOULD be sent as described below.
Proxy Echo Parameters TLVで指定されたTTLがチェックされ、[1,255]の範囲の値が含まれていることが確認されます。そうでない場合は、戻りコードを17に設定する必要があります（「プロキシPingパラメータを変更する必要があります」）。メッセージヘッダーの応答モードが1でない場合は、MPLSプロキシPing応答メッセージを以下のように送信する必要があります（SHOULD）。
If the "Request for FEC Neighbor Address info" flag is set, the Upstream Neighbor Address and Downstream Neighbor Address TLVs are formatted for inclusion in the MPLS Proxy Ping reply. If the Upstream or Downstream address is unknown, the corresponding TLV is omitted.
「Request for FEC Neighbor Address info」フラグが設定されている場合、アップストリームネイバーアドレスとダウンストリームネイバーアドレスのTLVは、MPLSプロキシping応答に含めるためにフォーマットされます。アップストリームまたはダウンストリームアドレスが不明な場合、対応するTLVは省略されます。
If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each address is examined to determine if it is a valid next hop for this FEC. If any are not, the Proxy Echo Parameters TLV SHOULD be updated to remove unrecognized Next Hop sub-TLVs. The updated Proxy Echo Parameters TLV MUST be included in the MPLS Proxy Ping Reply.
プロキシエコーパラメータTLVにネクストホップサブTLVがある場合、各アドレスが調べられ、このFECの有効なネクストホップであるかどうかが判断されます。ない場合は、プロキシエコーパラメータTLVを更新して、認識されないネクストホップサブTLVを削除する必要があります。更新されたプロキシエコーパラメータTLVは、MPLSプロキシping応答に含める必要があります。
If the "Request for Downstream Detailed Mapping" or "Request for Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion in the MPLS Proxy Ping Reply) a DS/DDMAP TLV for each interface over which the MPLS Echo Request will be sent.
「ダウンストリーム詳細マッピングのリクエスト」または「ダウンストリームマッピングのリクエスト」フラグが設定されている場合、プロキシLSRは、MPLSエコーリクエストが経由する各インターフェイスのDS / DDMAP TLVをフォーマットします（MPLSプロキシPing返信に含めるため）。送信されました。
If the Proxy LSR is the egress for the FEC, the behavior of the Proxy LSR varies depending on whether the LSR is an egress of a P2P LSP, a P2MP LSP, or MP2MP LSP. Additional details can be found in Section 3.2.1, "Proxy LSR Handling When It Is Egress for FEC".
プロキシLSRがFECの出力である場合、プロキシLSRの動作は、LSRがP2P LSP、P2MP LSP、またはMP2MP LSPの出力であるかどうかによって異なります。詳細は、3.2.1項「FECの出力である場合のプロキシLSR処理」を参照してください。
If the Reply Mode of the MPLS Proxy Ping Request message header is 1 ("Do not reply"), no MPLS Proxy Ping Reply is sent. Otherwise, an MPLS Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as described below.
MPLSプロキシPing要求メッセージヘッダーの返信モードが1（「返信しない」）の場合、MPLSプロキシPing返信は送信されません。それ以外の場合、MPLSプロキシPing応答メッセージまたはMPLSエコー要求は、以下に説明するように送信する必要があります（SHOULD）。
This section describes the different behaviors for the Proxy LSR when it's the egress for the FEC. In the P2MP bud node and MP2MP bud node egress cases, different behavior is required.
このセクションでは、FECの出力である場合のプロキシLSRのさまざまな動作について説明します。 P2MPバッドノードとMP2MPバッドノードの下りの場合、異なる動作が必要です。
In the case where an MPLS Echo Request is originated by an LSR that is a bud or egress node of a P2MP/MP2MP, MPLS Echo Replies are returned from downstream/upstream LSRs and will not include an MPLS Echo Reply from the LSR that originated the MPLS Echo Request. This section describes the behavior required at a bud or egress node to return or not return information from MPLS Echo Replies in the Proxy Echo Reply so that no changes are required in implementations that are compliant with [RFC4379]. The Proxy Initiator should receive the same MPLS Echo Replies as in the case of the originator of the LSP Ping; any additional information (such as the Proxy LSR being a bud or egress node) is returned in the MPLS Proxy Ping Reply.
MPLSエコー要求がP2MP / MP2MPのバッドまたは出力ノードであるLSRによって発信された場合、MPLSエコー応答はダウンストリーム/アップストリームLSRから返され、発信元のLSRからのMPLSエコー応答は含まれません。 MPLSエコー要求。このセクションでは、[RFC4379]に準拠した実装で変更を必要としないように、プロキシエコー応答でMPLSエコー応答から情報を返す、または返さないために、芽または出口ノードで必要な動作について説明します。プロキシイニシエーターは、LSP pingのオリジネーターの場合と同じMPLSエコー応答を受信する必要があります。追加情報（プロキシLSRがバッドノードまたは出力ノードであるなど）は、MPLSプロキシping応答で返されます。
When the Proxy LSR is the egress of a P2P FEC, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", with Return Subcode set to zero.
プロキシLSRがP2P FECの出力である場合、MPLSプロキシPing応答は、リターンコードが3に設定されたイニシエーターに送信される必要があります（「返信ルーターはスタック深度でのFECの出力」であり、リターンサブコードが設定されています）。ゼロに。
When the Proxy LSR is the egress of a P2MP FEC, it can be either a bud node or just an egress. If the Proxy LSR is a bud node, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero. DS/DDMAPs are included only if the Proxy Initiator requested information be returned in an MPLS Proxy Ping Reply. If the Proxy LSR is a bud node but there has not been a request to return an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the downstream neighbors (no MPLS Echo Reply is sent to the Proxy Initiator to indicate that the Proxy LSR is an egress). If the Proxy LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero.
プロキシLSRがP2MP FECの出力である場合、それはバッドノードまたは単なる出力のいずれかになります。プロキシLSRがバッドノードである場合、MPLSプロキシPing応答は、戻りコードが3に設定されたイニシエーターに送信される必要があります（「返信ルーターはスタック深度でのFECの出力」であり、戻りサブコードはゼロに設定されます）。 DS / DDMAPは、プロキシイニシエーターが情報をMPLSプロキシPing応答で返すように要求した場合にのみ含まれます。プロキシLSRがバッドノードであるが、MPLSプロキシPing応答を返す要求がない場合、プロキシLSRはMPLSエコー要求パケットをダウンストリームネイバーに送信する必要があります（MPLSエコー応答はプロキシイニシエーターに送信されません）。プロキシLSRが出力であることを示します）。プロキシLSRが単なる出力である場合、MPLSプロキシPing応答は、リターンコードが3に設定されたイニシエーターに送信される必要があります（「返信ルーターはスタック深度でのFECの出力」であり、リターンサブコードはゼロに設定されます）。
When the Proxy LSR is the egress of a MP2MP FEC, it can be either a bud node or just an egress. LSP Pings sent from a leaf of a MP2MP have different behavior in this case. MPLS Echo Requests are sent to all upstream/downstream neighbors. The Proxy LSRs need to be consistent with this variation in behavior. If the Proxy LSR is a bud node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the Proxy Initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", with Return Subcode set to zero and DS/DDMAPs included only if the Proxy Initiator requested information be returned in an MPLS Proxy Ping Reply. If the Proxy LSR is not requested to return information in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packets to all upstream/downstream neighbors as would be done when sourcing an LSP Ping from a MP2MP leaf (no MPLS Echo Reply is sent to the Proxy Initiator indicating that the Proxy LSR is an egress).
プロキシLSRがMP2MP FECの出力である場合、それはバッドノードまたは単なる出力のいずれかになります。この場合、MP2MPのリーフから送信されたLSP pingの動作は異なります。 MPLSエコー要求はすべてのアップストリーム/ダウンストリームネイバーに送信されます。プロキシLSRは、この動作のバリエーションと一貫している必要があります。プロキシLSRがバッドノードまたは単に出力の場合、MPLSプロキシPing応答は、戻りコードが3に設定されたプロキシイニシエータに送信されるべきである（SHOULD）、「返信ルータはスタック深度でのFECの出力」であり、戻りサブコードがゼロに設定され、DS / DDMAPは、プロキシイニシエーターが情報をMPLSプロキシping応答で返すように要求した場合にのみ含まれます。 MPLSプロキシPing応答で情報を返すようにプロキシLSRが要求されていない場合、MP2MPリーフからLSP Pingを取得するときに行われるように、プロキシLSRはすべての上流/下流ネイバーにMPLSエコー要求パケットを送信する必要があります（MPLSエコー応答なし）。プロキシLSRが出力であることを示すプロキシイニシエータに送信されます）。
When the Proxy LSR is a transit or bud node, downstream maps corresponding to how the packet is transited cannot be supplied unless an ingress interface for the MPLS Echo Request is specified. Since this information is not available and all valid output paths are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe the entire set of paths that the packet can be replicated. This is similar to the case in which an LSP Ping is initiated at the Proxy LSR. For mLDP, there is a DS/DDMAP per upstream/downstream neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case.
プロキシLSRがトランジットノードまたはバッドノードの場合、MPLSエコー要求の入力インターフェイスが指定されていないと、パケットのトランジット方法に対応するダウンストリームマップを提供できません。この情報は利用できず、すべての有効な出力パスが対象であるため、プロキシLSRには、パケットを複製できるパスのセット全体を説明するDS / DDMAPを含める必要があります（SHOULD）。これは、LSP pingがプロキシLSRで開始される場合に似ています。 mLDPの場合、MP2MP LSPのアップストリーム/ダウンストリームネイバーごと、またはP2MP LSPの場合はダウンストリームネイバーごとにDS / DDMAPがあります。
When the Proxy LSR is a bud node or egress in an MP2MP LSP or a bud node in a P2MP LSP, an LSP Ping initiated from the Proxy LSR would source packets only to the neighbors but not itself, despite the fact that the Proxy LSR is itself an egress for the FEC. In order to match the behavior as seen from LSP Ping initiated at the Proxy LSR, the Proxy Reply SHOULD contain DS/DDMAPs for only the paths to the upstream/downstream neighbors, but no DS/DDMAP describing its own egress paths. The proxy LSR identifies that it's an egress for the FEC using a different Proxy Reply Return Code. The Proxy Reply Return Code is either set to 19, "Replying router has FEC mapping for topmost FEC", or 3, "Replying router is an egress for the FEC at stack-depth".
プロキシLSRがMP2MP LSPのバッドノードまたは出力またはP2MP LSPのバッドノードである場合、プロキシLSRから開始されたLSP Pingは、プロキシLSRがそれ自体ではなく、ネイバーのみにパケットを送信します。それ自体がFECの出口です。プロキシLSRで開始されたLSP Pingから見られる動作と一致させるために、プロキシ応答には、上流/下流ネイバーへのパスのみのDS / DDMAPが含まれている必要がありますが、独自の出力パスを記述するDS / DDMAPは含まれていません。プロキシLSRは、それが別のプロキシ応答戻りコードを使用してFECの出口であることを識別します。プロキシ応答の戻りコードは19、「応答ルーターには最上位のFECのFECマッピングがあります」、または3、「応答ルーターはスタック深度のFECの出力」に設定されています。
The Reply Mode, Sender's Handle, and Sequence Number fields are copied from the Proxy Ping Request message. The TLVs specified above are included. The message is encapsulated in a UDP packet. The source IP address is a routable address of the Proxy LSR; the source port is the well-known UDP port for LSP Ping. The destination IP address and UDP port are copied from the source IP address and UDP port of the MPLS Proxy Ping Request. The IP TTL is set to 255.
[返信モード]、[送信者のハンドル]、および[シーケンス番号]フィールドは、プロキシping要求メッセージからコピーされます。上記で指定されたTLVが含まれます。メッセージはUDPパケットにカプセル化されます。送信元IPアドレスは、プロキシLSRのルーティング可能なアドレスです。送信元ポートは、LSP Pingの既知のUDPポートです。宛先IPアドレスとUDPポートは、MPLSプロキシping要求のソースIPアドレスとUDPポートからコピーされます。 IP TTLは255に設定されています。
An MPLS Echo Request is formed as described in the next section. The section below describes how the MPLS Echo Request is sent on each interface.
MPLSエコー要求は、次のセクションで説明するように形成されます。以下のセクションでは、各インターフェイスでMPLSエコー要求が送信される方法について説明します。
If Next Hop sub-TLVs were included in the received Proxy Echo Parameters TLV, the Next_Hop_List is created from the addresses in those sub-TLVs adjusted as described in Section 3.2. Otherwise, the list is set to all the next hops to which the FEC would be forwarded.
ネクストホップサブTLVが受信したプロキシエコーパラメータTLVに含まれていた場合、セクション3.2で説明されているように調整されたサブTLVのアドレスからNext_Hop_Listが作成されます。それ以外の場合、リストはFECが転送されるすべてのネクストホップに設定されます。
The Proxy LSR then formats an MPLS Echo Request message. The Global Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. The Return Code and Return Subcode are set to zero.
次に、プロキシLSRはMPLSエコー要求メッセージをフォーマットします。グローバルフラグと応答モードは、Proxy Echo Parameters TLVからコピーされます。戻りコードと戻りサブコードはゼロに設定されます。
The Sender's Handle and Sequence Number are copied from the remote MPLS Echo Request message.
送信者のハンドルとシーケンス番号は、リモートMPLSエコー要求メッセージからコピーされます。
The TimeStamp Sent is set to the time of day (in seconds and microseconds) that the MPLS Echo Request is sent. The TimeStamp Received is set to zero.
TimeStamp Sentは、MPLSエコー要求が送信される時刻（秒とマイクロ秒）に設定されます。 TimeStamp Receivedはゼロに設定されています。
If the Reply-to Address TLV is present, it is used to set the MPLS Echo Request source address; otherwise, the MPLS Echo Request source address is set to the Proxy Request source address.
返信先アドレスTLVが存在する場合は、それを使用してMPLSエコー要求の送信元アドレスを設定します。それ以外の場合、MPLSエコー要求の送信元アドレスは、プロキシ要求の送信元アドレスに設定されます。
The following TLVs are copied from the MPLS Proxy Ping Request message. Note that, of these, only the Target FEC Stack is REQUIRED to appear in the MPLS Proxy Ping Request message. The Pad TLV is not copied if the Proxy Echo Parameter TLV MPLS payload size is set to a non-zero value.
次のTLVは、MPLSプロキシPing要求メッセージからコピーされます。これらのうち、ターゲットFECスタックのみがMPLSプロキシPing要求メッセージに表示される必要があることに注意してください。プロキシエコーパラメータのTLV MPLSペイロードサイズがゼロ以外の値に設定されている場合、パッドTLVはコピーされません。
Target FEC Stack
ターゲットFECスタック
Pad
パッド
Vendor Enterprise Number
ベンダー企業番号
Reply TOS Byte
返信TOSバイト
P2MP Responder Identifier [RFC6425]
P2MPレスポンダー識別子[RFC6425]
Echo Jitter [RFC6425]
エコージッタ[RFC6425]
Vendor Private TLVs
ベンダーのプライベートTLV
If the Proxy Echo Parameter TLV MPLS payload size is non-zero, the Proxy LSR introduces a Pad TLV such that size of the MPLS Echo Request (including any IP and UDP header) is zero-padded to the specified MPLS payload size. The first octet in the Value part of the Pad TLV is set to 1, "Drop Pad TLV from reply", and the remaining octets of the Value part of the Pad TLV are filled with zeros. If the IP header is used to encapsulate the MPLS Echo Request, the DF bit MUST be set to one.
プロキシエコーパラメータTLV MPLSペイロードサイズがゼロ以外の場合、プロキシLSRはパッドTLVを導入し、MPLSエコー要求（IPおよびUDPヘッダーを含む）のサイズが、指定されたMPLSペイロードサイズにゼロパディングされます。パッドTLVの値部分の最初のオクテットは1、「応答からのパッドTLVの削除」に設定され、パッドTLVの値部分の残りのオクテットはゼロで埋められます。 IPヘッダーを使用してMPLSエコー要求をカプセル化する場合は、DFビットを1に設定する必要があります。
The message is then encapsulated in a UDP packet. The source UDP port is copied from the Proxy Echo Parameters TLV. The destination port is copied from the MPLS Proxy Ping Request message.
次に、メッセージはUDPパケットにカプセル化されます。ソースUDPポートは、Proxy Echo Parameters TLVからコピーされます。宛先ポートは、MPLSプロキシPing要求メッセージからコピーされます。
The source IP address is set to a routable address specified in the Reply-to Address TLV or the source address of the received Proxy Request. Per usual, the TTL of the IP packet is set to 1.
送信元IPアドレスは、返信先アドレスTLVで指定されたルーティング可能なアドレス、または受信したプロキシ要求の送信元アドレスに設定されます。通常、IPパケットのTTLは1に設定されています。
If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte is examined. If the setting is permitted, then the DSCP byte of the IP header of the MPLS Echo Request message is set to that value. If the Proxy LSR does not permit explicit control for the DSCP byte, the MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be included in any MPLS Proxy Ping Reply message to indicate why an MPLS Echo Request was not sent. The Return Code MUST be set to 17, "Proxy Ping parameters need to be modified". If the Explicit DSCP flag is not set, the Proxy LSR SHOULD set the MPLS Echo Request DSCP settings to the value normally used to source LSP Ping packets.
Explicit Differentiated Services Code Point（DSCP）フラグが設定されている場合、要求されたDSCPバイトが検査されます。設定が許可されると、MPLSエコー要求メッセージのIPヘッダーのDSCPバイトがその値に設定されます。プロキシLSRがDSCPバイトの明示的な制御を許可しない場合は、明示的なDSCPフラグがクリアされたMPLSプロキシエコーパラメータをMPLSプロキシping応答メッセージに含めて、MPLSエコー要求が送信されなかった理由を示す必要があります。リターンコードは17に設定する必要があります。「プロキシPingパラメータを変更する必要があります」。明示的DSCPフラグが設定されていない場合、プロキシLSRは、MPLSエコー要求DSCP設定を、LSP Pingパケットの送信元に通常使用される値に設定する必要があります（SHOULD）。
The Proxy LSR now iterates through the Next_Hop_List modifying the base MPLS Echo Request to form the MPLS Echo Request packet that is then sent on that particular interface.
プロキシLSRは、ベースMPLSエコー要求を変更するNext_Hop_Listを反復処理して、MPLSエコー要求パケットを形成し、その特定のインターフェイスで送信されます。
The outgoing label stack is determined for each next-hop address. The TTL for the label corresponding to the FEC specified in the FEC stack is set such that the TTL on the wire will be the TTL specified in the Proxy Echo Parameters. If any additional labels are pushed onto the stack, their TTLs are set to 255. This will ensure that the requestor will not have control over tunnels not relevant to the FEC being tested.
発信ラベルスタックは、ネクストホップアドレスごとに決定されます。 FECスタックで指定されたFECに対応するラベルのTTLは、ワイヤ上のTTLがプロキシエコーパラメータで指定されたTTLになるように設定されます。追加のラベルがスタックにプッシュされると、それらのTTLは255に設定されます。これにより、リクエスターがテスト対象のFECに関連しないトンネルを制御できないようになります。
If the MPLS Proxy Ping Request message contained Downstream Mapping TLVs or Downstream Detailed Mapping TLVs, they are examined. If the Downstream IP address matches the next-hop address, that Downstream Mapping TLV is included in the MPLS Echo Request.
MPLSプロキシping要求メッセージにダウンストリームマッピングTLVまたはダウンストリーム詳細マッピングTLVが含まれている場合、それらが検査されます。ダウンストリームIPアドレスがネクストホップアドレスと一致する場合、そのダウンストリームマッピングTLVはMPLSエコー要求に含まれます。
The packet is then transmitted on this interface.
その後、パケットはこのインターフェイスで送信されます。
This document defines two new LSP Ping messages, the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply.
このドキュメントでは、MPLSプロキシPing要求とMPLSプロキシPing応答という2つの新しいLSP Pingメッセージを定義しています。
The packet format is as defined in [RFC4379]. Two new message types, Proxy Ping Request and Reply, are being added.
パケットフォーマットは[RFC4379]で定義されているとおりです。 2つの新しいメッセージタイプ、Proxy Ping RequestおよびReplyが追加されています。
Message Type
メッセージタイプ
Type Message
---- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
The MPLS Proxy Ping Request message MAY contain the following TLVs:
MPLSプロキシping要求メッセージには、次のTLVが含まれる場合があります。
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
3 Pad
5 Vendor Enterprise Number
10 Reply TOS Byte
11 P2MP Responder Identifier [RFC6425]
12 Echo Jitter [RFC6425]
20 Downstream Detailed Mapping
21 Reply Path [RFC7110]
22 Reply TC [RFC7110]
23 Proxy Echo Parameters
24 Reply-to Address
* Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be ignored if not understood
* ベンダープライベートTLVスペースのTLVタイプは、理解できない場合は無視する必要があります
The MPLS Proxy Ping Reply message MAY contain the following TLVs:
MPLSプロキシPing応答メッセージには、次のTLVが含まれる場合があります。
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
5 Vendor Enterprise Number
9 Errored TLVs
20 Downstream Detailed Mapping
23 Proxy Echo Parameters
25 Upstream Neighbor Address
26 Downstream Neighbor Address (0 or more)
* Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be ignored if not understood
* ベンダープライベートTLVスペースのTLVタイプは、理解できない場合は無視する必要があります
The Proxy Echo Parameters TLV is a TLV that MUST be included in an MPLS Proxy Ping Request message. The length of the TLV is 12 + K + S, where K is the length of the Destination IP Address field and S is the total length of the sub-TLVs. The Proxy Echo Parameters TLV can be used either to 1) control attributes used in composing and sending an MPLS Echo Request or 2) query the Proxy LSR for information about the topmost FEC in the target FEC stack, but not both. In the case where the Proxy LSR is being queried (i.e., information needs to be returned in an MPLS Proxy Ping Reply), no MPLS Echo Request will be sent from the Proxy LSR. The MPLS Proxy Ping Request Proxy Echo Parameters TLV's Proxy Flags SHOULD be set appropriately, as described below.
プロキシエコーパラメータTLVは、MPLSプロキシping要求メッセージに含める必要があるTLVです。 TLVの長さは12 + K + Sです。ここで、Kは宛先IPアドレスフィールドの長さ、SはサブTLVの全長です。プロキシエコーパラメータTLVは、1）MPLSエコー要求の作成と送信に使用される属性を制御するか、2）プロキシLSRに、ターゲットFECスタックの最上位FECに関する情報を照会しますが、両方には使用できません。プロキシLSRが照会されている場合（つまり、情報がMPLSプロキシPing応答で返される必要がある場合）、MPLSエコー要求はプロキシLSRから送信されません。 MPLSプロキシpingリクエストプロキシエコーパラメータTLVのプロキシフラグは、以下で説明するように適切に設定する必要があります（SHOULD）。
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 | Reply Mode | Proxy Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Rqst'd DSCP | Source UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Flags | MPLS Payload Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Destination IP Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Sub-TLVs :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
住所タイプ
The type and length of the address found in the in the Destination IP Address and Next Hop IP Addresses fields. The values are shared with the Downstream Mapping Address Type Registry.
Destination IP AddressおよびNext Hop IP Addressesフィールドにあるアドレスのタイプと長さ。値は、ダウンストリームマッピングアドレスタイプレジストリと共有されます。
The type codes applicable in this case appear in the table below:
この場合に適用されるタイプコードを以下の表に示します。
Address Family Type Length
アドレスファミリタイプの長さ
IPv4 1 4 IPv6 3 16
IPv4 1 4 IPv6 3 16
Reply Mode
返信モード
The reply mode to be sent in the MPLS Echo Request message; the values are as specified in [RFC4379].
MPLSエコー要求メッセージで送信される応答モード。値は[RFC4379]で指定されたとおりです。
Proxy Flags
プロキシフラグ
The Proxy Request Initiator sets zero, one, or more of these flags to request actions at the Proxy LSR.
プロキシリクエストイニシエーターは、これらのフラグを0個、1個、またはそれ以上設定して、プロキシLSRでアクションを要求します。
0x0001 Request for FEC Neighbor Address info
0x0001 FECネイバーアドレス情報の要求
When set, this requests that the Proxy LSR supply the Upstream and Downstream neighbor address information in the MPLS Proxy Ping Reply message. This flag is only applicable for the topmost FEC in the FEC stack if the FEC type corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST respond (as applicable) with Upstream Neighbor Address and Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping Reply message. The Upstream Neighbor Address TLV needs be included only if there is an upstream neighbor. Similarly, one Downstream Neighbor Address TLV needs to be included for each Downstream Neighbor from which the LSR learned bindings.
設定されている場合、これは、プロキシLSRがMPLSプロキシping応答メッセージでアップストリームおよびダウンストリームネイバーアドレス情報を提供することを要求します。このフラグは、FECタイプがP2MPまたはMP2MP LSPに対応する場合、FECスタックの最上位のFECにのみ適用されます。プロキシLSRは、MPLSプロキシPing応答メッセージ内のアップストリームネイバーアドレスとダウンストリームネイバーアドレスTLVで（該当する場合）応答する必要があります。アップストリームネイバーアドレスTLVは、アップストリームネイバーがある場合にのみ含める必要があります。同様に、LSRがバインディングを学習したダウンストリームネイバーごとに、1つのダウンストリームネイバーアドレスTLVを含める必要があります。
Setting this flag will cause the Proxy LSR to cancel sending any MPLS Echo Request. The initiator may use information learned from the MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests.
このフラグを設定すると、プロキシLSRはMPLSエコー要求の送信をキャンセルします。イニシエータは、代わりに送信されるMPLSプロキシPing応答から学習した情報を使用して、後続のプロキシ要求を生成できます。
0x0002 Request for Downstream Mapping
0x0002ダウンストリームマッピングの要求
When set, this requests that the Proxy LSR supply a Downstream Mapping TLV (see [RFC4379]) in the MPLS Proxy Ping Reply message. Either this flag may be set or the "Request for Downstream Detailed Mapping" flag may be set, but not both.
設定されると、これは、プロキシLSRがMPLSプロキシPing応答メッセージでダウンストリームマッピングTLV（[RFC4379]を参照）を提供することを要求します。このフラグを設定するか、「ダウンストリーム詳細マッピングのリクエスト」フラグを設定することができますが、両方は設定できません。
Setting this flag will cause the Proxy LSR to cancel sending an MPLS Echo Request. Information learned with such a Proxy Reply may be used by the Proxy Initiator to generate subsequent Proxy Requests.
このフラグを設定すると、プロキシLSRはMPLSエコー要求の送信をキャンセルします。このようなプロキシ応答で学習した情報は、プロキシイニシエータが後続のプロキシ要求を生成するために使用できます。
0x0004 Request for Downstream Detailed Mapping
0x0004ダウンストリーム詳細マッピングの要求
When set, this requests that the Proxy LSR supply a Downstream Detailed Mapping TLV (see [RFC6424]) in the MPLS Proxy Ping Reply message. It's not valid to have the "Request for Downstream Mapping" flag set when this flag is set. Setting this flag will cause the Proxy LSR to cancel sending an MPLS Echo Request. The initiator may use information learned from the MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests.
設定されると、これは、プロキシLSRがMPLSプロキシPing応答メッセージでダウンストリーム詳細マッピングTLV（[RFC6424]を参照）を提供することを要求します。このフラグが設定されているときに「ダウンストリームマッピングの要求」フラグを設定することは無効です。このフラグを設定すると、プロキシLSRはMPLSエコー要求の送信をキャンセルします。イニシエータは、代わりに送信されるMPLSプロキシPing応答から学習した情報を使用して、後続のプロキシ要求を生成できます。
0x0008 Explicit DSCP Request
0x0008明示的なDSCP要求
When set, this requests that the Proxy LSR use the supplied "Rqst'd DSCP" byte in the Echo Request message
設定されている場合、これは、プロキシLSRがエコー要求メッセージで指定された「Rqst'd DSCP」バイトを使用することを要求します
TTL
TTL
The TTL to be used in the label stack entry corresponding to the topmost FEC in the MPLS Echo Request packet. Valid values are in the range [1,255].
MPLSエコー要求パケットの最上位のFECに対応するラベルスタックエントリで使用されるTTL。有効な値の範囲は[1,255]です。
Requested DSCP
要求されたDSCP
This field is valid only if the Explicit DSCP flag is set. If not set, the field MUST be zero on transmission and ignored on receipt. When the flag is set, this field contains the DSCP value to be used in the MPLS Echo Request packet IP header.
このフィールドは、明示的なDSCPフラグが設定されている場合にのみ有効です。設定されていない場合、フィールドは送信時にゼロであり、受信時に無視される必要があります。フラグが設定されている場合、このフィールドには、MPLSエコー要求パケットのIPヘッダーで使用されるDSCP値が含まれます。
Source UDP Port
ソースUDPポート
The source UDP port to be sent in the MPLS Echo Request packet
MPLSエコー要求パケットで送信される送信元UDPポート
Global Flags
グローバルフラグ
The Global Flags to be sent in the MPLS Echo Request message
MPLSエコー要求メッセージで送信されるグローバルフラグ
MPLS Payload Size
MPLSペイロードサイズ
Used to request that the MPLS payload (IP header + UDP header + MPLS Echo Request) be padded using a zero-filled Pad TLV so that the IP header, UDP header, and MPLS Echo Request total the specified size. Having the field set to zero means no size request is being made. If the requested size is less than the minimum size required to form the MPLS Echo Request, the request will be treated as a best-effort request with the Proxy LSR building the smallest possible packet (i.e., not using a Pad TLV). The IP header DF bit MUST be set when this field is non-zero.
MPLSペイロード（IPヘッダー+ UDPヘッダー+ MPLSエコー要求）にゼロで埋められたパッドTLVを使用してパディングして、IPヘッダー、UDPヘッダー、およびMPLSエコー要求が指定されたサイズになるように要求するために使用されます。フィールドをゼロに設定すると、サイズの要求は行われません。要求されたサイズがMPLSエコー要求を形成するために必要な最小サイズより小さい場合、その要求は、可能な限り最小のパケットを構築する（つまり、パッドTLVを使用しない）プロキシLSRによるベストエフォート要求として扱われます。このフィールドがゼロ以外の場合、IPヘッダーのDFビットを設定する必要があります。
Destination IP Address
宛先IPアドレス
If the Address Type is IPv4, an address from the range 127/8;
if the Address Type is IPv6, an address from the range
::ffff:7f00:0/104
Sub-TLVs
サブTLV
List of TLV-encoded sub-TLVs. Currently one is defined.
TLVでエンコードされたサブTLVのリスト。現在1つ定義されています。
Sub-Type Length Sub-TLV Name
-------- ------ ------------
1 8+ Next Hop
This sub-TLV is used to describe a particular next hop towards which the Echo Request packet should be sent. If the topmost FEC in the FEC stack is a multipoint LSP, this sub-TLV may appear multiple times.
このサブTLVは、エコー要求パケットの送信先である特定のネクストホップを記述するために使用されます。 FECスタックの最上位のFECがマルチポイントLSPである場合、このサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Interface (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
住所タイプ
Type Type of Next Hop Addr Length Interface Field (IF) Length 1 IPv4 Numbered 4 4 2 IPv4 Unnumbered 4 4 3 IPv6 Numbered 16 16 4 IPv6 Unnumbered 16 4 5 Reserved 6 IPv4 Protocol Adj 4 0 7 IPv6 Protocol Adj 16 0
タイプNext Hop Addrのタイプ長さインターフェイスフィールド（IF）長さ1 IPv4番号付き4 4 2 IPv4番号なし4 4 3 IPv6番号付き16 16 4 IPv6番号なし16 4 5予約済み6 IPv4プロトコル調整4 0 7 IPv6プロトコル調整16 0
Note: Types 1-4 correspond to the types in the DSMAP TLV. They are expected to be populated with information obtained through a previously returned DSMAP TLV. Types 6 and 7 are intended to be populated from the local address information obtained from a previously returned Downstream Neighbor Address TLV or Upstream Neighbor Address TLV.
注：タイプ1から4は、DSMAP TLVのタイプに対応しています。これらには、以前に返されたDSMAP TLVを通じて取得した情報が入力されることが期待されています。タイプ6および7は、以前に返されたダウンストリームネイバーアドレスTLVまたはアップストリームネイバーアドレスTLVから取得したローカルアドレス情報から入力することを目的としています。
Next Hop IP Address
ネクストホップIPアドレス
A next hop address that the Echo Request message is to be sent towards
エコー要求メッセージが送信されるネクストホップアドレス
Next Hop Interface
ネクストホップインターフェイス
Identifier of the interface through which the Echo Request message is to be sent. For Addr Type 5 and 6, the Next Hop interface field isn't used and MUST be of an associated byte length of zero octets.
エコー要求メッセージが送信されるインターフェースの識別子。 Addr Type 5および6の場合、Next Hopインターフェースフィールドは使用されず、関連するバイト長が0オクテットである必要があります。
Used to specify the MPLS Echo Request IP source address. This address MUST be IP reachable via the Proxy LSR; otherwise, it will be rejected.
MPLSエコー要求IP送信元アドレスを指定するために使用されます。このアドレスは、プロキシLSR経由でIP到達可能でなければなりません。それ以外の場合は拒否されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Reply-to Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
住所タイプ
A type code as specified in the table below:
以下の表で指定されているタイプコード：
Type Type of Address
タイプアドレスのタイプ
1 IPv4 3 IPv6
1 IPv4 3 IPv6
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Upst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Upstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upst Addr Type; Local Addr Type
上位アドレスタイプ。ローカルアドレスタイプ
These two fields determine the type and length of the respective addresses. The codes are specified in the table below:
これらの2つのフィールドは、それぞれのアドレスのタイプと長さを決定します。コードは以下の表で指定されています。
Type Type of Address Length
タイプアドレスのタイプ長さ
0 No Address Supplied 0 1 IPv4 4 3 IPv6 16
0アドレスなし0 1 IPv4 4 3 IPv6 16
Upstream Address
アップストリームアドレス
The address of the immediate upstream neighbor for the topmost FEC in the FEC stack. If the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange.
FECスタックの最上位FECのすぐ上流のネイバーのアドレス。このFECのラベルが交換されたプロトコル隣接が存在する場合、このアドレスは、そのプロトコル交換で使用されるアドレスである必要があります。
Local Address
ローカルアドレス
The local address used in the protocol adjacency by which the label for this FEC was exchanged.
このFECのラベルが交換されたプロトコル隣接で使用されるローカルアドレス。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Dnst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Downstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dnst Addr Type; Local Addr Type
Dstアドレスタイプ。ローカルアドレスタイプ
These two fields determine the type and length of the respective addresses. The codes are specified in the table below:
これらの2つのフィールドは、それぞれのアドレスのタイプと長さを決定します。コードは以下の表で指定されています。
Type Type of Address Length
タイプアドレスのタイプ長さ
0 No Address Supplied 0 1 IPv4 4 3 IPv6 16
0アドレスなし0 1 IPv4 4 3 IPv6 16
Downstream Address
ダウンストリームアドレス
The address of an immediate downstream neighbor for the topmost FEC in the FEC stack. If the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange.
FECスタックの最上位FECの直接のダウンストリームネイバーのアドレス。このFECのラベルが交換されたプロトコル隣接が存在する場合、このアドレスは、そのプロトコル交換で使用されるアドレスである必要があります。
Local Address
ローカルアドレス
The local address used in the protocol adjacency by which the label for this FEC was exchanged.
このFECのラベルが交換されたプロトコル隣接で使用されるローカルアドレス。
The mechanisms described in this document are intended to be used within a service provider network and to be initiated only under the authority of that administration.
このドキュメントで説明されているメカニズムは、サービスプロバイダーネットワーク内で使用され、その管理者の権限の下でのみ開始されることを目的としています。
If such a network also carries Internet traffic, or permits IP access from other administrations, the MPLS Proxy Ping message SHOULD be discarded at the points where IP packets are received from other administrations. This can be accomplished by filtering on source address or by filtering all MPLS ping messages on UDP port.
そのようなネットワークがインターネットトラフィックも伝送する場合、または他の行政機関からのIPアクセスを許可する場合、MPLSプロキシPingメッセージは、他の行政機関からIPパケットを受信した時点で破棄する必要があります（SHOULD）。これは、送信元アドレスでフィルタリングするか、UDPポートですべてのMPLS pingメッセージをフィルタリングすることで実現できます。
Any node that acts as a Proxy LSR SHOULD validate requests against a set of valid source addresses. An implementation MUST provide such filtering capabilities.
プロキシLSRとして機能するノードは、有効な送信元アドレスのセットに対してリクエストを検証する必要があります（SHOULD）。実装は、このようなフィルタリング機能を提供する必要があります。
MPLS Proxy Ping Request messages are IP addressed directly to the Proxy LSR. If a Proxy LSR receives an MPLS Proxy Ping message via expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted upon.
MPLSプロキシping要求メッセージは、プロキシLSRに直接IPアドレスが割り当てられます。プロキシLSRがIPまたはラベルスタックエントリTTLの期限切れを介してMPLSプロキシPingメッセージを受信する場合、それに応じてはなりません。
If an MPLS Proxy Ping Request IP source address is not IP reachable by the Proxy LSR, the Proxy Request MUST NOT be acted upon.
MPLSプロキシping要求のIPソースアドレスがプロキシLSRからIP到達可能でない場合、プロキシ要求に基づいて動作してはなりません（MUST NOT）。
MPLS Proxy Ping Requests are limited to making their request via the specification of a FEC. This ensures that only valid MPLS Echo Request messages can be created. No label-spoofing attacks are possible.
MPLSプロキシPing要求は、FECの仕様を介した要求に限定されます。これにより、有効なMPLSエコー要求メッセージのみを作成できるようになります。ラベルスプーフィング攻撃は不可能です。
Per this document, IANA has made the following assignments.
このドキュメントに従って、IANAは次の割り当てを行いました。
MPLS LSP Ping Message Types
MPLS LSP pingメッセージタイプ
Value Meaning
----- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
TLVs
TLV
Type TLV Name
---- --------
23 Proxy Echo Parameters
24 Reply-to Address
25 Upstream Neighbor Address
26 Downstream Neighbor Address
Return Codes
戻りコード
Value Meaning
----- -------
16 Proxy Ping not authorized
17 Proxy Ping parameters need to be modified
18 MPLS Echo Request could not be sent
19 Replying router has FEC mapping for topmost FEC
The IANA has created and maintains this new registry for Proxy Echo Parameters Sub-TLVs. Assignments will use the same rules spelled out in Section 7.2 of [RFC4379].
IANAは、Proxy Echo Parameters Sub-TLVのこの新しいレジストリを作成および維持しています。割り当てには、[RFC4379]のセクション7.2に記載されているのと同じルールが使用されます。
Sub-Type Sub-TLV Name
-------- ------------
0 Reserved
1 Next Hop
IANA has created and maintains a new registry for the Proxy Flags that are used with the Proxy Echo Parameters TLV. See Section 5.1 for details. The registry is in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Multiprotocol Label Switching Architecture (MPLS)" name space. The registration procedure is Standards Action [RFC5226]. The initial values are as follows.
IANAは、Proxy Echo Parameters TLVで使用されるプロキシフラグ用の新しいレジストリを作成および維持しています。詳細については、セクション5.1を参照してください。レジストリは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）」名前空間の「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）Pingパラメータ」レジストリにあります。登録手続きは、Standards Action [RFC5226]です。初期値は以下の通りです。
Bit Number Name
---------- ----
0 Request for FEC Neighbor Address info
1 Request for Downstream Mapping
2 Request for Downstream Detailed Mapping
3 Explicit DSCP Request
4-15 Unassigned
This document makes the following assignments in the Downstream Address Mapping Registry. This document updates the registry defined by [RFC6426]. The registration procedure remains Standards Action and a note has been added as follows:
このドキュメントでは、ダウンストリームアドレスマッピングレジストリで次の割り当てを行います。このドキュメントは、[RFC6426]によって定義されたレジストリを更新します。登録手順は標準アクションのままで、次のように注記が追加されています。
When a code point is assigned that is not also assigned in the Next Hop Address Type Registry, the code point there must be marked "Reserved".
ネクストホップアドレスタイプレジストリでも割り当てられていないコードポイントが割り当てられている場合、そのコードポイントには「予約済み」のマークを付ける必要があります。
Type # Address Type K Octets
------ ------------ --------
6 Reserved N/A RFC 7555
7 Reserved N/A RFC 7555
IANA has created a new registry called the "Next Hop Address Type Registry". The allocation policy for this registry is Standards Action. Further, a note has been added as follows:
IANAは、「ネクストホップアドレスタイプレジストリ」と呼ばれる新しいレジストリを作成しました。このレジストリの割り当てポリシーは標準アクションです。さらに、次のように注記が追加されました。
When a code point is assigned that is not also assigned in the Downstream Address Mapping Registry, the code point there must be marked "Reserved".
ダウンストリームアドレスマッピングレジストリでも割り当てられていないコードポイントが割り当てられている場合、そのコードポイントには「予約済み」のマークを付ける必要があります。
The initial allocations are:
初期割り当ては次のとおりです。
Type Type of Next Hop Addr Length IF Length Reference
タイプNext Hop Addr長さのタイプIF長さの参照
1 IPv4 Numbered 4 4 [RFC4379]
2 IPv4 Unnumbered 4 4 [RFC4379]
3 IPv6 Numbered 16 16 [RFC4379]
4 IPv6 Unnumbered 16 4 [RFC4379]
5 Reserved RFC 7555
6 IPv4 Protocol Adj 4 0 RFC 7555
7 IPv6 Protocol Adj 16 0 RFC 7555
8-255 Unassigned
[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>。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, <http://www.rfc-editor.org/info/rfc6424>.
[RFC6424] Bahadur、N.、Kompella、K。、およびG. Swallow、「MPLSトンネル上でラベルスイッチドパスPing（LSP Ping）を実行するメカニズム」、RFC 6424、DOI 10.17487 / RFC6424、2011年11月、<http：/ /www.rfc-editor.org/info/rfc6424>。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <http://www.rfc-editor.org/info/rfc6425>.
[RFC6425] Saxena、S.、Ed。、Swallow、G.、Ali、Z.、Farrel、A.、Yasukawa、S.、and T. Nadeau、 "Detecting Data-Plane Failures in Point-to-Multipoint MPLS- LSP Pingの拡張機能」、RFC 6425、DOI 10.17487 / RFC6425、2011年11月、<http://www.rfc-editor.org/info/rfc6425>。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, DOI 10.17487/RFC6426, November 2011, <http://www.rfc-editor.org/info/rfc6426>.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、DOI 10.17487 / RFC6426、2011年11月、<http：/ /www.rfc-editor.org/info/rfc6426>。
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <http://www.rfc-editor.org/info/rfc7110>.
[RFC7110] Chen、M.、Cao、W.、Ning、S.、Jounay、F。、およびS. Delord、「Return Path Specified Label Switched Path（LSP）Ping」、RFC 7110、DOI 10.17487 / RFC7110、January 2014、<http://www.rfc-editor.org/info/rfc7110>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[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>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、DOI 10.17487 / RFC6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
Acknowledgements
謝辞
The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Yu, Tom Taylor, and Warren Kumari for their detailed reviews and insightful comments.
著者は、詳細なレビューと洞察に満ちたコメントを提供してくれた、Noki Akiya、Adrian Farrel、Tom Yu、Tom Taylor、およびWarren Kumariに感謝します。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 United States
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough、MA 01719アメリカ合衆国
EMail: swallow@cisco.com
Vanson Lim Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States
ゔぁんそん ぃｍ しｓこ Ｓｙｓてｍｓ １４１４ まっさちゅせっｔｓ あゔぇぬえ ぼｘぼろうｇｈ、 ま ０１７１９ うにてｄ Ｓたてｓ
EMail: vlim@cisco.com
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara、CA 95951アメリカ合衆国
EMail: aldrin.ietf@gmail.com