[要約] RFC 7746は、Label Switched Path (LSP) Self-Pingの仕様を定義しています。この仕様の目的は、LSPの状態を監視し、問題を早期に検出することです。
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 7746 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
M. Conn
D. Pacella
L. Tomotaki
Verizon
January 2016
Label Switched Path (LSP) Self-Ping
ラベルスイッチドパス（LSP）の自己ping
Abstract
概要
When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
特定のRSVP-TE最適化が実装されている場合、すべてのダウンストリームノードに転送状態がインストールされる前に、入力ラベルスイッチングルータ（LSR）がRSVP RESVメッセージを受信できます。 RSVP-TE仕様によれば、入力LSRは、RESVメッセージを受信するとすぐに、ラベルスイッチドパス（LSP）を介してトラフィックを転送できます。ただし、すべてのダウンストリームノードに転送状態がインストールされる前に、入力LSRがLSPを介してトラフィックを転送すると、トラフィックが失われる可能性があります。
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.
このドキュメントでは、LSPセルフpingについて説明します。入力LSRがRESVメッセージを受信すると、LSP Self-pingプロシージャを呼び出して、すべてのダウンストリームノードに転送状態がインストールされていることを確認できます。
LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP Self-pingは新しいプロトコルです。 LSP Pingの拡張ではありません。 LSP PingとLSP Self-pingは同じように命名されていますが、それぞれ独自の目的で設計されています。各プロトコルは独自のUDPポートでリッスンし、独自の手順を実行します。
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.
LSP Self-pingは非常に軽量なメカニズムです。送信または出力LSRでコントロールプレーンリソースを消費しません。
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. 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/rfc7746.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2を参照してください。このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/infoで入手できます。 / rfc7746。
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.
この文書は、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
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 6
4. LSP Self-Ping Procedures . . . . . . . . . . . . . . . . . . 7
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Ingress Label Switching Routers (LSRs) use RSVP-TE [RFC3209] to establish MPLS Label Switched Paths (LSPs). The following paragraphs describe RSVP-TE procedures.
入力ラベルスイッチングルータ（LSR）は、RSVP-TE [RFC3209]を使用してMPLSラベルスイッチドパス（LSP）を確立します。次の段落では、RSVP-TE手順について説明します。
The ingress LSR calculates a path between itself and an egress LSR. The calculated path can be either strictly or loosely routed. Having calculated a path, the ingress LSR constructs an RSVP PATH message. The PATH message includes an Explicit Route Object (ERO) that represents the path between the ingress and egress LSRs.
入力LSRは、それ自体と出力LSRの間のパスを計算します。計算されたパスは、厳密にルーティングすることも、緩くルーティングすることもできます。パスを計算すると、入力LSRはRSVP PATHメッセージを作成します。 PATHメッセージには、入力LSRと出力LSRの間のパスを表す明示ルートオブジェクト（ERO）が含まれています。
The ingress LSR forwards the PATH message towards the egress LSR, following the path defined by the ERO. Each transit LSR that receives the PATH message executes admission control procedures. If the transit LSR admits the LSP, it sends the PATH message downstream, to the next node in the ERO.
入力LSRは、EROによって定義されたパスに従って、PATHメッセージを出力LSRに転送します。 PATHメッセージを受信する各中継LSRは、アドミッション制御手順を実行します。トランジットLSRがLSPを許可すると、PATHメッセージをダウンストリームでEROの次のノードに送信します。
When the egress LSR receives the PATH message, it binds a label to the LSP. The label can be implicit null, explicit null, or non-null. The egress LSR then installs forwarding state (if necessary) and constructs an RSVP RESV message. The RESV message contains a Label Object that includes the label that has been bound to the LSP.
出力LSRがPATHメッセージを受信すると、LSPにラベルをバインドします。ラベルは、暗黙的ヌル、明示的ヌル、または非ヌルにすることができます。次に、出力LSRは転送状態をインストールし（必要な場合）、RSVP RESVメッセージを作成します。 RESVメッセージには、LSPにバインドされたラベルを含むラベルオブジェクトが含まれています。
The egress LSR sends the RESV message upstream towards the ingress LSR. The RESV message visits the same transit LSRs that the PATH message visited, in reverse order. Each transit LSR binds a label to the LSP, updates its forwarding state, and updates the RESV message. As a result, the Label Object in the RESV message contains the label that has been bound to the LSP most recently. Finally, the transit LSR sends the RESV message upstream, along the reverse path of the LSP.
出力LSRは、RESVメッセージをアップストリームの入力LSRに向けて送信します。 RESVメッセージは、PATHメッセージが訪問したのと同じトランジットLSRを逆の順序で訪問します。各中継LSRはラベルをLSPにバインドし、その転送状態を更新し、RESVメッセージを更新します。その結果、RESVメッセージのラベルオブジェクトには、最後にLSPにバインドされたラベルが含まれています。最後に、トランジットLSRはLSPの逆のパスに沿ってRESVメッセージをアップストリームに送信します。
When the ingress LSR receives the RESV message, it installs forwarding state. Once the ingress LSR installs forwarding state, it can forward traffic through the LSP.
入力LSRはRESVメッセージを受信すると、転送状態をインストールします。入力LSRが転送状態をインストールすると、LSPを介してトラフィックを転送できます。
Referring to any LSR, RFC 3209 says, "The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message." However, RFC 3209 does not strictly require this behavior.
LSRについては、RFC 3209で、「ノードは、Resvメッセージを送信する前に、割り当てられたラベルを含むパケットを転送する準備をしておく必要があります。」ただし、RFC 3209はこの動作を厳密に要求していません。
Some implementations optimize the above-described procedure by allowing LSRs to send RESV messages before installing forwarding state [RFC6383]. This optimization is desirable, because it allows LSRs to install forwarding state in parallel, thus accelerating the process of LSP signaling and setup. However, this optimization creates a race condition. When the ingress LSR receives a RESV message, some downstream LSRs may have not yet installed forwarding state. If the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
一部の実装では、転送状態をインストールする前にLSRがRESVメッセージを送信できるようにすることで、上記の手順を最適化しています[RFC6383]。この最適化により、LSRが転送状態を並行してインストールできるようになるため、LSPシグナリングとセットアップのプロセスが加速されます。ただし、この最適化により競合状態が発生します。入力LSRがRESVメッセージを受信したとき、一部のダウンストリームLSRはまだ転送状態をインストールしていない可能性があります。すべてのダウンストリームノードに転送状態がインストールされる前に、入力LSRがLSPを介してトラフィックを転送すると、トラフィックが失われる可能性があります。
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to verify that forwarding state has been installed on all downstream nodes. By verifying the installation of downstream forwarding state, the ingress LSR eliminates this particular cause of traffic loss.
このドキュメントでは、LSPセルフpingについて説明します。入力LSRがRESVメッセージを受信すると、LSPセルフpingプロシージャを呼び出して、すべてのダウンストリームノードに転送状態がインストールされていることを確認できます。ダウンストリーム転送状態のインストールを確認することにより、入力LSRはトラフィック損失のこの特定の原因を排除します。
LSP Self-ping is a new protocol. It is not an extension of LSP Ping [RFC4379]. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP Self-pingは新しいプロトコルです。 LSP Ping [RFC4379]の拡張ではありません。 LSP PingとLSP Self-pingは同じように命名されていますが、それぞれ独自の目的で設計されています。各プロトコルは独自のUDPポートでリッスンし、独自の手順を実行します。
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.
LSP Self-pingは非常に軽量なメカニズムです。送信または出力LSRでコントロールプレーンリソースを消費しません。
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 Self-ping is applicable in the following scenario:
LSPセルフpingは、次のシナリオに適用できます。
o The ingress LSR signals a point-to-point LSP.
o 入力LSRは、ポイントツーポイントLSPを通知します。
o The ingress LSR receives a RESV message.
o 入力LSRはRESVメッセージを受信します。
o The RESV message indicates that all downstream nodes have begun the process of forwarding state installation.
o RESVメッセージは、すべてのダウンストリームノードが状態のインストールの転送プロセスを開始したことを示しています。
o The RESV message does not guarantee that all downstream nodes have completed the process of forwarding state installation.
o RESVメッセージは、すべてのダウンストリームノードが転送状態のインストールプロセスを完了したことを保証するものではありません。
o The ingress LSR needs to confirm that all downstream nodes have completed the process for forwarding state installation.
o 入力LSRは、すべてのダウンストリームノードが転送状態のインストールのプロセスを完了したことを確認する必要があります。
o The ingress LSR does not need to confirm the correctness of downstream forwarding state, because there is a very high likelihood that downstream forwarding state is correct.
o ダウンストリームフォワーディングステートが正しい可能性が非常に高いため、入力LSRはダウンストリームフォワーディングステートの正確性を確認する必要はありません。
o Control-plane resources on the egress LSR may be scarce.
o 出力LSRのコントロールプレーンリソースが不足している可能性があります。
o The need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct.
o 出力LSRのコントロールプレーンリソースを節約する必要性は、ダウンストリーム転送状態が正しいかどうかを判断する必要性よりも重要です。
Unlike LSP Ping and S-BFD [S-BFD], LSP Self-ping is not a general-purpose MPLS OAM mechanism. It cannot reliably determine whether downstream forwarding state is correct. For example, if a downstream LSR installs a forwarding state that causes an LSP to terminate at the wrong node, LSP Self-ping will not detect an error. In another example, if a downstream LSR erroneously forwards a packet without an MPLS label, LSP Self-ping will not detect an error.
LSP PingおよびS-BFD [S-BFD]とは異なり、LSP Self-pingは汎用MPLS OAMメカニズムではありません。ダウンストリームの転送状態が正しいかどうかを確実に判断することはできません。たとえば、ダウンストリームLSRがLSPを間違ったノードで終了させるフォワーディングステートをインストールした場合、LSPセルフpingはエラーを検出しません。別の例では、ダウンストリームLSRがMPLSラベルのないパケットを誤って転送した場合、LSPセルフpingはエラーを検出しません。
Furthermore, LSP Self-ping fails when either of the following conditions are true:
さらに、次のいずれかの条件に該当する場合、LSPセルフpingは失敗します。
o The LSP under test is signaled by the Label Distribution Protocol (LDP) Independent Mode [RFC5036].
o テスト中のLSPは、ラベル配布プロトコル（LDP）独立モード[RFC5036]によって通知されます。
o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on links that connect the ingress LSR to the egress LSR.
o リバースパス転送（RPF）[RFC3704]フィルターは、入力LSRを出力LSRに接続するリンクで有効になります。
While LSP Ping and S-BFD are general-purpose OAM mechanisms, they are not applicable in the above-described scenario because:
LSP PingおよびS-BFDは汎用OAMメカニズムですが、次の理由により、上記のシナリオには適用できません。
o LSP Ping consumes control-plane resources on the egress LSR.
o LSP Pingは、出力LSRのコントロールプレーンリソースを消費します。
o An S-BFD implementation either consumes control-plane resources on the egress LSR or requires special support for S-BFD on the forwarding plane.
o S-BFDの実装では、出力LSRのコントロールプレーンリソースを消費するか、転送プレーンでのS-BFDの特別なサポートが必要です。
By contrast, LSP Self-ping requires nothing from the egress LSR beyond the ability to forward an IP datagram.
対照的に、LSPセルフpingには、IPデータグラムを転送する機能以外に、出力LSRからの要求はありません。
LSP Self-ping's purpose is to determine whether forwarding state has been installed on all downstream LSRs. Its primary constraint is to minimize its impact on egress LSR performance. This functionality is valuable during network convergence events that impact a large number of LSPs.
LSP Self-pingの目的は、すべてのダウンストリームLSRに転送状態がインストールされているかどうかを確認することです。その主な制約は、出力LSRパフォーマンスへの影響を最小限に抑えることです。この機能は、多数のLSPに影響を与えるネットワーク収束イベントの際に役立ちます。
Therefore, LSP Self-ping is applicable in the scenario described above, where the LSP is signaled by RSVP, RPF is not enabled, and the need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct.
したがって、LSPセルフpingは、LSPがRSVPによってシグナリングされ、RPFが有効ではなく、出力LSRのコントロールプレーンリソースを節約する必要性が、ダウンストリーム転送状態が正しい。
The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC768] packet that encapsulates a session ID. If the RSVP messages used to establish the LSP under test were delivered over IPv4 [RFC791], the UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP messages used to establish the LSP were delivered over IPv6 [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header.
LSPセルフpingメッセージは、セッションIDをカプセル化するユーザーデータグラムプロトコル（UDP）[RFC768]パケットです。テスト対象のLSPを確立するために使用されるRSVPメッセージがIPv4 [RFC791]経由で配信された場合、UDPデータグラムはIPv4ヘッダーにカプセル化される必要があります。 LSPの確立に使用されるRSVPメッセージがIPv6 [RFC2460]経由で配信された場合、UDPデータグラムはIPv6ヘッダーにカプセル化されなければなりません（MUST）。
In either case:
どちらの場合にも：
o The IP Source Address MAY be configurable. By default, it MUST be the address of the egress LSR.
o IP送信元アドレスは構成可能である場合があります。デフォルトでは、出力LSRのアドレスでなければなりません。
o The IP Destination Address MUST be the address of the ingress LSR.
o IP宛先アドレスは、入力LSRのアドレスでなければなりません。
o The IP Time to Live (TTL) / Hop Count MAY be configurable. By default, it MUST be 255.
o IP Time to Live（TTL）/ホップカウントは構成可能です。デフォルトでは、255にする必要があります。
o The IP DSCP (Differentiated Services Code Point) MAY be configurable. By default, it MUST be CS6 (110000) [RFC4594].
o IP DSCP（Differentiated Services Code Point）は構成可能である場合があります。デフォルトでは、CS6（110000）[RFC4594]である必要があります。
o The UDP Source Port MUST be selected from the dynamic range (49152-65535) [RFC6335].
o UDPソースポートはダイナミックレンジ（49152-65535）[RFC6335]から選択する必要があります。
o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS]
o UDP宛先ポートはlsp-self-ping（8503）である必要があります[IANA.PORTS]
UDP packet contents have the following format:
UDPパケットの内容は次の形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Self-Ping Message
LSP自己pingメッセージ
The Session-ID is a 64-bit field that associates an LSP Self-ping message with an LSP Self-ping session.
セッションIDは、LSPセルフpingメッセージをLSPセルフpingセッションに関連付ける64ビットのフィールドです。
In order to verify that an LSP is ready to carry traffic, the ingress LSR creates a short-lived LSP Self-ping session. All session state is maintained locally on the ingress LSR. Session state includes the following information:
LSPがトラフィックを伝送する準備ができていることを確認するために、入力LSRは短期間のLSPセルフpingセッションを作成します。すべてのセッション状態は、入力LSRでローカルに維持されます。セッション状態には次の情報が含まれます。
o Session-ID: A 64-bit number that identifies the LSP Self-ping session.
o セッションID：LSPセルフpingセッションを識別する64ビットの番号。
o Retry Counter: The maximum number of times that the ingress LSR probes the LSP before terminating the LSP Self-ping session. The initial value of this variable is determined by configuration.
o Retry Counter：入力LSRがLSP Self-pingセッションを終了する前にLSPをプローブする最大回数。この変数の初期値は、構成によって決まります。
o Retry Timer: The number of milliseconds that the LSR waits after probing the LSP. The initial value of this variable is determined by configuration.
o 再試行タイマー：LSPのプローブ後にLSRが待機するミリ秒数。この変数の初期値は、構成によって決まります。
o Status: A boolean variable indicating the completion status of the LSP Self-ping session. The initial value of this variable is FALSE.
o ステータス：LSPセルフpingセッションの完了ステータスを示すブール変数。この変数の初期値はFALSEです。
Implementations MAY represent the above-mentioned information in any format that is convenient to them.
実装は、それらに都合のよい任意の形式で上記の情報を表すことができます。
The ingress LSR executes the following procedure until Status equals TRUE or Retry Counter equals zero:
入力LSRは、ステータスがTRUEまたはリトライカウンタがゼロになるまで、次の手順を実行します。
o Format a LSP Self-ping message.
o LSP Self-pingメッセージをフォーマットします。
o Set the Session-ID in the LSP Self-ping message to the Session-ID mentioned above.
o LSP Self-pingメッセージのセッションIDを上記のセッションIDに設定します。
o Send the LSP Self-ping message through the LSP under test.
o テスト対象のLSPを介してLSP Self-pingメッセージを送信します。
o Set a timer to expire in Retry Timer milliseconds.
o 再試行タイマーミリ秒でタイマーが期限切れになるように設定します。
o Wait until either an LSP Self-ping message associated with the session returns or the timer expires. If an LSP Self-ping message associated with the session returns, set Status to TRUE. Otherwise, decrement the Retry Counter. Optionally, increase the value of Retry Timer according to an appropriate back-off algorithm.
o セッションに関連付けられたLSP Self-pingメッセージが返されるか、タイマーが期限切れになるまで待ちます。セッションに関連付けられたLSP Self-pingメッセージが返される場合は、StatusをTRUEに設定します。それ以外の場合は、再試行カウンターをデクリメントします。必要に応じて、適切なバックオフアルゴリズムに従って再試行タイマーの値を増やします。
In the process described above, the ingress LSR addresses an LSP Self-ping message to itself and forwards that message through the LSP under test. If forwarding state has been installed on all downstream LSRs, the egress LSR receives the LSP Self-ping message and determines that it is addressed to the ingress LSR. So, the egress LSR forwards the LSP Self-ping message back to the ingress LSR, exactly as it would forward any other IP packet.
上記のプロセスでは、入力LSRがLSPセルフpingメッセージを自分宛てに送信し、テスト中のLSPを介してそのメッセージを転送します。転送状態がすべてのダウンストリームLSRにインストールされている場合、出力LSRはLSPセルフpingメッセージを受信し、それが入力LSRにアドレス指定されていると判断します。そのため、出力LSRは、他のIPパケットを転送する場合とまったく同じように、LSP Self-pingメッセージを入力LSRに転送します。
The LSP Self-ping message can arrive at the egress LSR with or without an MPLS header, depending on whether the LSP under test executes penultimate hop-popping procedures. If the LSP Self-ping message arrives at the egress LSR with an MPLS header, the egress LSR removes that header.
LSPセルフpingメッセージは、テスト対象のLSPが最後から2番目のホップポップ手順を実行するかどうかに応じて、MPLSヘッダーの有無にかかわらず出力LSRに到着します。 LSP Self-pingメッセージがMPLSヘッダー付きの出力LSRに到着すると、出力LSRはそのヘッダーを削除します。
If the egress LSR's most preferred route to the ingress LSR is through an LSP, the egress LSR forwards the LSP Self-ping message through that LSP. However, if the egress LSR's most preferred route to the ingress LSR is not through an LSP, the egress LSR forwards the LSP Self-ping message without MPLS encapsulation.
入力LSRへの出力LSRの最も優先されるルートがLSPを経由する場合、出力LSRはそのLSPを介してLSPセルフpingメッセージを転送します。ただし、入力LSRへの出力LSRの最も優先されるルートがLSPを経由しない場合、出力LSRはMPLSカプセル化なしでLSPセルフpingメッセージを転送します。
When an LSP Self-ping session terminates, it returns its completion status to the invoking protocol. For example, if RSVP-TE invokes LSP Self-ping as part of the LSP setup procedure, LSP Self-ping returns its completion status to RSVP-TE.
LSPセルフpingセッションが終了すると、その完了ステータスを呼び出しプロトコルに返します。たとえば、RSVP-TEがLSPセットアップ手順の一部としてLSPセルフpingを呼び出すと、LSPセルフpingはその完了ステータスをRSVP-TEに返します。
A bidirectional LSP has an active side and a passive side. The active side calculates the ERO and signals the LSP in the forward direction. The passive side reverses the ERO and signals the LSP in the reverse direction.
双方向LSPには、アクティブ側とパッシブ側があります。アクティブサイドはEROを計算し、LSPを順方向に通知します。パッシブ側はEROを反転し、LSPに逆方向に信号を送ります。
When LSP Self-ping is applied to a bidirectional LSP:
LSPセルフpingが双方向LSPに適用される場合：
o The active side calculates the ERO, signals the LSP, and runs LSP Self-ping.
o アクティブ側は、EROを計算し、LSPに信号を送り、LSPセルフpingを実行します。
o The Passive side reverses the ERO, signals the LSP, and runs another instance of LSP Self-ping.
o パッシブ側は、EROを反転し、LSPに信号を送り、LSPセルフpingの別のインスタンスを実行します。
o Neither side forwards traffic through the LSP until local LSP Self-ping returns TRUE.
o ローカルLSPセルフpingがTRUEを返すまで、どちらの側もLSPを介してトラフィックを転送しません。
The two LSP Self-ping sessions mentioned above are independent of one another. They are not required to have the same Session-ID. Each endpoint can forward traffic through the LSP as soon as its local LSP Self-ping returns TRUE. Endpoints are not required to wait until both LSP Self-ping sessions have returned TRUE.
上記の2つのLSP Self-pingセッションは、互いに独立しています。同じSession-IDを持つ必要はありません。各エンドポイントは、ローカルのLSP Self-pingがTRUEを返すとすぐに、LSPを介してトラフィックを転送できます。エンドポイントは、両方のLSP Self-pingセッションがTRUEを返すまで待機する必要はありません。
IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by MPLS LSP Self-Ping.
IANAは、MPLS LSP Self-Pingで使用するUDPポート番号8503 [IANA.PORTS]を割り当てています。
LSP Self-ping messages are easily forged. Therefore, an attacker can send the ingress LSR a forged LSP Self-ping message, causing the ingress LSR to terminate the LSP Self-ping session prematurely. In order to mitigate these threats, operators SHOULD filter LSP Self-ping packets at the edges of the MPLS signaling domain. Furthermore, implementations SHOULD NOT assign Session-IDs in a predictable manner. In order to avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) [NIST-CSPRNG].
LSP Self-pingメッセージは簡単に偽造されます。したがって、攻撃者は入力LSRに偽造されたLSP Self-pingメッセージを送信し、入力LSRがLSP Self-pingセッションを途中で終了させる可能性があります。これらの脅威を軽減するために、オペレーターはMPLSシグナリングドメインのエッジでLSP Self-pingパケットをフィルタリングする必要があります（SHOULD）。さらに、実装は予測可能な方法でセッションIDを割り当てるべきではありません。予測可能性を回避するために、実装では、暗号的に安全な疑似乱数ジェネレータ（CSPRNG）[NIST-CSPRNG]を利用できます。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[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>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704 >。
[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>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[IANA.PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.
[IANA.PORTS] IANA、「サービス名とトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/ service-names-port-numbers>。
[NIST-CSPRNG] NIST, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012.
[NIST-CSPRNG] NIST、「決定論的乱数ビットジェネレーターを使用した乱数生成の推奨」、NIST Special Publication 800-90A、2012年1月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]バビアス、J。、チャン、K。、およびF.ベイカー、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<http://www.rfc-editor.org / info / rfc4594>。
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 2011, <http://www.rfc-editor.org/info/rfc6383>.
[RFC6383] Shiomoto、K。およびA. Farrel、「RSVP-TEを使用して確立されたラベルスイッチドパスでデータの送信を開始しても安全な場合のアドバイス」、RFC 6383、DOI 10.17487 / RFC6383、2011年9月、<http：// www.rfc-editor.org/info/rfc6383>。
[S-BFD] Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Networks, "Seamless Bidirectional Forwarding Detection (S-BFD)", Work in Progress, draft-ietf-bfd-seamless-base-05, June 2015.
[S-BFD] Akiya、N.、Pignataro、C.、Ward、D.、Bhatia、M。、およびJ. Networks、「Seamless Bidirectional Forwarding Detection（S-BFD）」、Work in Progress、draft-ietf- bfd-seamless-base-05、2015年6月。
In a rejected approach, the ingress LSR uses LSP Ping to verify LSP readiness. This approach was rejected for the following reasons.
拒否されたアプローチでは、入力LSRはLSP Pingを使用してLSPの準備を確認します。このアプローチは、次の理由で拒否されました。
While an ingress LSR can control its control-plane overhead due to LSP Ping, an egress LSR has no such control. This is because each ingress LSR can, on its own, control the rate of the LSP Ping originated by the LSR, while an egress LSR must respond to all the LSP Pings originated by various ingresses. Furthermore, when an MPLS Echo Request reaches an egress LSR, it is sent to the control plane of the egress LSR; this makes egress LSR processing overhead of LSP Ping well above the overhead of its data plane (MPLS/IP forwarding). These factors make LSP Ping problematic as a tool for detecting LSP readiness to carry traffic when dealing with a large number of LSPs.
入力LSRはLSP Pingによりコントロールプレーンオーバーヘッドを制御できますが、出力LSRにはそのような制御はありません。これは、各入力LSRがそれ自体でLSRによって発信されたLSP Pingのレートを制御できる一方で、出力LSRはさまざまな入力によって発信されたすべてのLSP Pingに応答する必要があるためです。さらに、MPLSエコー要求が出力LSRに到達すると、出力LSRのコントロールプレーンに送信されます。これにより、LSP pingの出力LSR処理オーバーヘッドが、データプレーン（MPLS / IP転送）のオーバーヘッドをはるかに上回ります。これらの要因により、LSP pingは、大量のLSPを処理するときにLSPがトラフィックを伝送する準備ができているかどうかを検出するツールとして問題になります。
By contrast, LSP Self-ping does not consume any control-plane resources at the egress LSR, and it relies solely on the data plane of the egress LSR, making it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs.
対照的に、LSPセルフpingは出力LSRでコントロールプレーンリソースを消費せず、出力LSRのデータプレーンのみに依存しているため、多数を処理する場合のLSP準備状況をチェックするツールとしてより適しています。 LSPの。
In another rejected approach, the ingress LSR does not verify LSP readiness. Instead, it sets a timer when it receives an RSVP RESV message and does not forward traffic through the LSP until the timer expires. This approach was rejected because it is impossible to determine the optimal setting for this timer. If the timer value is set too low, it does not prevent black-holing. If the timer value is set too high, it slows down the process of LSP signaling and setup.
別の拒否されたアプローチでは、入力LSRはLSPの準備を確認しません。代わりに、RSVP RESVメッセージを受信したときにタイマーを設定し、タイマーが期限切れになるまでLSPを介してトラフィックを転送しません。このタイマーの最適な設定を決定することが不可能であるため、このアプローチは拒否されました。タイマー値の設定が低すぎると、ブラックホールが防止されません。タイマー値の設定が高すぎると、LSPシグナリングとセットアップのプロセスが遅くなります。
Moreover, the above-mentioned timer is configured on a per-router basis. However, its optimum value is determined by a network-wide behavior. Therefore, changes in the network could require changes to the value of the timer, making the optimal setting of this timer a moving target.
さらに、上記のタイマーはルーターごとに構成されます。ただし、その最適値はネットワーク全体の動作によって決まります。したがって、ネットワークの変更にはタイマーの値の変更が必要になる可能性があり、このタイマーの最適設定を移動ターゲットにします。
Acknowledgements
謝辞
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Mirsky, and Nobo Akiya for their contributions to this document.
この文書への貢献に対して、Yakov Rekhter、Ravi Singh、Eric Rosen、Eric Osborne、Greg Mirsky、およびNobo Akiyaに感謝します。
Contributors
貢献者
The following individuals contributed significantly to this document:
以下の個人がこの文書に大きく貢献しました：
Mark Wygant Verizon mark.wygant@verizon.com
Mark Wygant Verizon mark.wygant@verizon.com
Ravi Torvi Juniper Networks rtorvi@juniper.net
Ravi Torvi Juniper Networks rtorvi@juniper.net
Authors' Addresses
著者のアドレス
Ron Bonica Juniper Networks
ロンボニカジュニパーネットワークス
Email: rbonica@juniper.net
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ
Email: inaminei@google.com
Michael Conn Verizon
マイケル・コン・ベライゾン
Email: meconn26@gmail.com
Dante Pacella Verizon
ダンテパチェッラベライゾン
Email: dante.j.pacella@verizon.com
Luis Tomotaki Verizon
ルイス友滝ベライゾン
Email: luis.tomotaki@verizon.com