[要約] RFC 5884は、MPLSラベルスイッチドパス（LSPs）のための双方向転送検出（BFD）に関する規格です。このRFCの目的は、MPLSネットワークでのLSPの状態を監視し、障害を早期に検出することです。
Internet Engineering Task Force (IETF) R. Aggarwal
Request for Comments: 5884 K. Kompella
Updates: 1122 Juniper Networks
Category: Standards Track T. Nadeau
ISSN: 2070-1721 BT
G. Swallow
Cisco Systems, Inc.
June 2010
Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）
Abstract
概要
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment.
双方向転送検出（BFD）の望ましいアプリケーションの1つは、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）データプレーンの障害を検出することです。 LSP Pingは、MPLSデータプレーンの障害を検出し、コントロールプレーンに対してMPLS LSPデータプレーンを確認するための既存のメカニズムです。前者にはBFDを使用できますが、後者には使用できません。ただし、BFDコントロールパケットに必要なコントロールプレーン処理は、LSP Pingメッセージに必要な処理よりも比較的小さくなります。 LSP PingとBFDの組み合わせを使用して、より高速なデータプレーン障害検出を提供したり、より多くのLSPでそのような検出を提供したりできます。このドキュメントでは、このアプリケーションのLSP Pingに関連するBFDの適用性について説明します。この環境でBFDを使用する手順についても説明します。
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/rfc5884.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5884で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Applicability ...................................................3
3.1. BFD for MPLS LSPs: Motivation ..............................3
3.2. Using BFD in Conjunction with LSP Ping .....................5
4. Theory of Operation .............................................6
5. Initialization and Demultiplexing ...............................7
6. Session Establishment ...........................................7
6.1. BFD Discriminator TLV in LSP Ping ..........................8
7. Encapsulation ...................................................8
8. Security Considerations .........................................9
9. IANA Considerations ............................................10
10. Acknowledgments ...............................................10
11. References ....................................................10
11.1. Normative References .....................................10
11.2. Informative References ...................................10
One desirable application of Bidirectional Forwarding Detection (BFD) is to track the liveness of a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP). In particular, BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. LSP Ping [RFC4379] is an existing mechanism for detecting MPLS LSP data plane failures and for verifying the MPLS LSP data plane against the control plane. This document describes the applicability of BFD in relation to LSP Ping for detecting MPLS LSP data plane failures. It also describes procedures for using BFD for detecting MPLS LSP data plane failures.
双方向転送検出（BFD）の望ましいアプリケーションの1つは、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）の活性を追跡することです。特に、BFDは、MPLS LSPの転送パスでデータプレーンの障害を検出するために使用できます。 LSP Ping [RFC4379]は、MPLS LSPデータプレーンの障害を検出し、コントロールプレーンに対してMPLS LSPデータプレーンを検証するための既存のメカニズムです。このドキュメントでは、MPLS LSPデータプレーンの障害を検出するためのLSP pingに関連するBFDの適用性について説明します。また、MPLS LSPデータプレーンの障害を検出するためにBFDを使用する手順についても説明します。
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]で説明されているように解釈されます。
In the event of an MPLS LSP failing to deliver data traffic, it may not always be possible to detect the failure using the MPLS control plane. For instance, the control plane of the MPLS LSP may be functional while the data plane may be mis-forwarding or dropping data. Hence, there is a need for a mechanism to detect a data plane failure in the MPLS LSP path [RFC4377].
MPLS LSPがデータトラフィックの配信に失敗した場合、MPLSコントロールプレーンを使用して障害を常に検出できるとは限りません。たとえば、MPLS LSPのコントロールプレーンは機能している可能性がありますが、データプレーンはデータを誤って転送またはドロップしています。したがって、MPLS LSPパス[RFC4377]でデータプレーンの障害を検出するメカニズムが必要です。
LSP Ping described in [RFC4379] is an existing mechanism for detecting an MPLS LSP data plane failure. In addition, LSP Ping also provides a mechanism for verifying the MPLS control plane against the data plane. This is done by ensuring that the LSP is mapped to the same Forwarding Equivalence Class (FEC), at the egress, as the ingress.
[RFC4379]で説明されているLSP Pingは、MPLS LSPデータプレーンの障害を検出するための既存のメカニズムです。さらに、LSP Pingは、データプレーンに対してMPLSコントロールプレーンを検証するメカニズムも提供します。これは、LSPが出口で、入口と同じ転送等価クラス（FEC）にマップされるようにすることで行われます。
BFD cannot be used for verifying the MPLS control plane against the data plane. However, BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. The LSP may be associated with any of the following FECs:
BFDは、データプレーンに対するMPLSコントロールプレーンの確認には使用できません。ただし、BFDを使用して、MPLS LSPの転送パスのデータプレーン障害を検出できます。 LSPは、次のFECのいずれかに関連付けることができます。
a) Resource Reservation Protocol (RSVP) LSP_Tunnel IPv4/IPv6 Session [RFC3209]
a) リソース予約プロトコル（RSVP）LSP_Tunnel IPv4 / IPv6セッション[RFC3209]
b) Label Distribution Protocol (LDP) IPv4/IPv6 prefix [RFC5036]
b) ラベル配布プロトコル（LDP）IPv4 / IPv6プレフィックス[RFC5036]
c) Virtual Private Network (VPN) IPv4/IPv6 prefix [RFC4364] d) Layer 2 VPN [L2-VPN]
c）仮想プライベートネットワーク（VPN）IPv4 / IPv6プレフィックス[RFC4364] d）レイヤー2 VPN [L2-VPN]
e) Pseudowires based on PWid FEC and Generalized PWid FEC [RFC4447]
e) PWid FECおよび一般化されたPWid FECに基づく疑似配線[RFC4447]
f) Border Gateway Protocol (BGP) labeled prefixes [RFC3107]
f) ボーダーゲートウェイプロトコル（BGP）ラベル付きプレフィックス[RFC3107]
LSP Ping includes extensive control plane verification. BFD, on the other hand, was designed as a lightweight means of testing only the data plane. As a result, LSP Ping is computationally more expensive than BFD for detecting MPLS LSP data plane faults. BFD is also more suitable for being implemented in hardware or firmware due to its fixed packet format. Thus, the use of BFD for detecting MPLS LSP data plane faults has the following advantages:
LSP Pingには、広範なコントロールプレーン検証が含まれています。一方、BFDは、データプレーンのみをテストする軽量な手段として設計されました。その結果、LSP Pingは、MPLS LSPデータプレーンの障害を検出するために、BFDよりも計算コストが高くなります。 BFDは、固定パケット形式のため、ハードウェアまたはファームウェアでの実装にも適しています。したがって、MPLS LSPデータプレーンの障害を検出するためにBFDを使用すると、次の利点があります。
a) Support for fault detection for greater number of LSPs.
a) より多くのLSPの障害検出のサポート。
b) Fast detection. Detection with sub-second granularity is considered as fast detection. LSP Ping is intended to be used in an environment where fault detection messages are exchanged, either for diagnostic purposes or for infrequent periodic fault detection, in the order of tens of seconds or minutes. Hence, it is not appropriate for fast detection. BFD, on the other hand, is designed for sub-second fault detection intervals. Following are some potential cases when fast detection may be desirable for MPLS LSPs:
b) 高速検出。 1秒未満の粒度での検出は、高速検出と見なされます。 LSP Pingは、診断目的または頻繁ではない定期的な障害検出のために、数十秒または数分のオーダーで障害検出メッセージが交換される環境で使用することを目的としています。したがって、高速検出には適していません。一方、BFDは1秒未満の障害検出間隔用に設計されています。以下は、MPLS LSPで高速検出が望ましい場合があるいくつかの潜在的なケースです。
1. In the case of a bypass LSP used for a facility-based link or node protection [RFC4090]. In this case, the bypass LSP is essentially being used as an alternate link to protect one or more LSPs. It represents an aggregate and is used to carry data traffic belonging to one or more LSPs, when the link or the node being protected fails. Hence, fast failure detection of the bypass LSP may be desirable particularly in the event of link or node failure when the data traffic is moved to the bypass LSP.
1. ファシリティベースのリンクまたはノード保護に使用されるバイパスLSPの場合[RFC4090]。この場合、バイパスLSPは基本的に1つ以上のLSPを保護するための代替リンクとして使用されています。これは集約を表し、リンクまたは保護されているノードに障害が発生したときに、1つ以上のLSPに属するデータトラフィックを運ぶために使用されます。したがって、特にデータトラフィックがバイパスLSPに移動されたときにリンクまたはノードに障害が発生した場合は、バイパスLSPの高速障害検出が望ましい場合があります。
2. MPLS Pseudowires (PWs). Fast detection may be desired for MPLS PWs depending on i) the model used to layer the MPLS network with the Layer 2 network, and ii) the service that the PW is emulating. For a non-overlay model between the Layer 2 network and the MPLS network, the provider may rely on PW fault detection to provide service status to the end-systems. Also, in that case, interworking scenarios such as ATM/Frame Relay interworking may force periodic PW fault detection messages. Depending on the requirements of the service that the MPLS PW is emulating, fast failure detection may be desirable.
2. MPLS疑似配線（PW）。 MPLS PWでは、i）MPLSネットワークをレイヤー2ネットワークとレイヤー化するために使用されるモデル、およびii）PWがエミュレートするサービスに応じて、高速検出が必要になる場合があります。レイヤ2ネットワークとMPLSネットワーク間の非オーバーレイモデルの場合、プロバイダーはPW障害検出に依存して、エンドシステムにサービスステータスを提供します。また、その場合、ATM /フレームリレーインターワーキングなどのインターワーキングシナリオは、定期的なPW障害検出メッセージを強制する可能性があります。 MPLS PWがエミュレートしているサービスの要件によっては、高速な障害検出が望ましい場合があります。
There may be other potential cases where fast failure detection is desired for MPLS LSPs.
MPLS LSPで高速な障害検出が望まれる他の潜在的なケースが存在する可能性があります。
BFD can be used for MPLS LSP data plane fault detection. However, it does not have all the functionality of LSP Ping. In particular, it cannot be used for verifying the control plane against the data plane. LSP Ping performs the following functions that are outside the scope of BFD:
BFDは、MPLS LSPデータプレーンの障害検出に使用できます。ただし、LSP Pingのすべての機能を備えているわけではありません。特に、データプレーンに対するコントロールプレーンの検証には使用できません。 LSP Pingは、BFDの範囲外の次の機能を実行します。
a) Association of an LSP Ping Echo request message with a FEC. In the case of Penultimate Hop Popping (PHP) or when the egress Label Switching Router (LSR) distributes an explicit null label to the penultimate hop router, for a single label stack LSP, the only way to associate a fault detection message with a FEC is by carrying the FEC in the message. LSP Ping provides this functionality. Next-hop label allocation also makes it necessary to carry the FEC in the fault detection message as the label alone is not sufficient to identify the LSP being verified. In addition, presence of the FEC in the Echo request message makes it possible to verify the control plane against the data plane at the egress LSR.
a) LSP Ping Echo要求メッセージとFECの関連付け。 Penultimate Hop Popping（PHP）の場合、または出力ラベルスイッチングルーター（LSR）が明示的なnullラベルを最後から2番目のホップルーターに配布する場合、単一のラベルスタックLSPについて、障害検出メッセージをFECに関連付ける唯一の方法メッセージにFECを含めることによるものです。 LSP Pingはこの機能を提供します。ネクストホップラベル割り当てでは、検証されているLSPを識別するのにラベルだけでは不十分であるため、障害検出メッセージでFECを運ぶ必要があります。さらに、エコー要求メッセージにFECが存在することで、出力LSRでデータプレーンに対してコントロールプレーンを検証できます。
b) Equal Cost Multi-Path (ECMP) considerations. LSP Ping traceroute makes it possible to probe multiple alternate paths for LDP IP FECs.
b) 等コストマルチパス（ECMP）の考慮事項。 LSP ping tracerouteを使用すると、LDP IP FECの複数の代替パスをプローブできます。
c) Traceroute. LSP Ping supports traceroute for a FEC and it can be used for fault isolation.
c) Traceroute。 LSP PingはFECのtracerouteをサポートしており、障害分離に使用できます。
Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault detection:
したがって、BFDはLSP Pingと組み合わせてMPLS LSP障害検出に使用されます。
i) LSP Ping is used for bootstrapping the BFD session as described later in this document.
i) このドキュメントで後述するように、LSP PingはBFDセッションのブートストラップに使用されます。
ii) BFD is used to exchange fault detection (i.e., BFD session) packets at the required detection interval.
ii）BFDは、必要な検出間隔で障害検出（つまり、BFDセッション）パケットを交換するために使用されます。
iii) LSP Ping is used to periodically verify the control plane against the data plane by ensuring that the LSP is mapped to the same FEC, at the egress, as the ingress.
iii）LSP pingを使用して、LSPが入力と同じFECに出力としてマッピングされるようにすることにより、データプレーンに対してコントロールプレーンを定期的に検証します。
To use BFD for fault detection on an MPLS LSP, a BFD session MUST be established for that particular MPLS LSP. BFD Control packets MUST be sent along the same data path as the LSP being verified and are processed by the BFD processing module of the egress LSR. If the LSP is associated with multiple FECs, a BFD session SHOULD be established for each FEC. For instance, this may happen in the case of next-hop label allocation. Hence, the operation is conceptually similar to the data plane fault detection procedures of LSP Ping.
MPLS LSPの障害検出にBFDを使用するには、その特定のMPLS LSPに対してBFDセッションを確立する必要があります。 BFD制御パケットは、検証中のLSPと同じデータパスに沿って送信する必要があり、出力LSRのBFD処理モジュールによって処理されます。 LSPが複数のFECに関連付けられている場合は、FECごとにBFDセッションを確立する必要があります（SHOULD）。たとえば、これはネクストホップラベル割り当ての場合に発生する可能性があります。したがって、動作はLSP Pingのデータプレーン障害検出手順と概念的に似ています。
If MPLS fast-reroute is being used for the MPLS LSP, the use of BFD for fault detection can result in false fault detections if the BFD fault detection interval is less than the MPLS fast-reroute switchover time. When MPLS fast-reroute is triggered because of a link or node failure, BFD Control packets will be dropped until traffic is switched on to the backup LSP. If the time taken to perform the switchover exceeds the BFD fault detection interval, a fault will be declared even though the MPLS LSP is being locally repaired. To avoid this, the BFD fault detection interval should be greater than the fast-reroute switchover time. An implementation SHOULD provide configuration options to control the BFD fault detection interval.
MPLS LSPにMPLS高速リルートが使用されている場合、BFD障害検出間隔がMPLS高速リルートスイッチオーバー時間よりも短いと、障害検出にBFDを使用すると、誤った障害検出が発生する可能性があります。リンクまたはノードの障害によりMPLS高速リルートがトリガーされると、トラフィックがバックアップLSPに切り替えられるまで、BFD制御パケットはドロップされます。スイッチオーバーの実行にかかる時間がBFD障害検出間隔を超えると、MPLS LSPがローカルで修復されていても、障害が宣言されます。これを回避するには、BFD障害検出間隔を高速リルートスイッチオーバー時間より長くする必要があります。実装は、BFD障害検出間隔を制御する構成オプションを提供する必要があります（SHOULD）。
If there are multiple alternate paths from an ingress LSR to an egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to determine each of these alternate paths. A BFD session SHOULD be established for each alternate path that is discovered.
LDP IP FECの入力LSRから出力LSRへの複数の代替パスがある場合、LSP ping tracerouteを使用して、これらの代替パスのそれぞれを決定できます。検出された代替パスごとにBFDセッションを確立する必要があります（SHOULD）。
Periodic LSP Ping Echo request messages SHOULD be sent by the ingress LSR to the egress LSR along the same data path as the LSP. This is to periodically verify the control plane against the data plane by ensuring that the LSP is mapped to the same FEC, at the egress, as the ingress. The rate of generation of these LSP Ping Echo request messages SHOULD be significantly less than the rate of generation of the BFD Control packets. An implementation MAY provide configuration options to control the rate of generation of the periodic LSP Ping Echo request messages.
定期的なLSP Ping Echo要求メッセージは、LSPと同じデータパスに沿って入力LSRから出力LSRに送信する必要があります（SHOULD）。これは、LSPが出口と入口で同じFECにマッピングされていることを確認することにより、データプレーンに対してコントロールプレーンを定期的に検証するためです。これらのLSP Ping Echo要求メッセージの生成率は、BFD制御パケットの生成率よりも大幅に低くする必要があります（SHOULD）。実装は、定期的なLSP Ping Echo要求メッセージの生成率を制御する構成オプションを提供する場合があります。
To enable fault detection procedures specified in this document, for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured. This includes configuration for supporting BFD and LSP Ping as specified in this document. It also includes configuration that enables the ingress LSR to determine the method used by the egress LSR to identify Operations, Administration, and Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of the innermost MPLS label needs to be set to 1 to enable the egress LSR to identify the OAM packet. For fault detection for MPLS PWs, this document assumes that the PW control channel type [RFC5085] is configured and the support of LSP Ping is also configured.
このドキュメントで指定されている障害検出手順を有効にするには、特定のMPLS LSPについて、このドキュメントで入力および出力LSRを設定する必要があります。これには、このドキュメントで指定されているBFDおよびLSP Pingをサポートするための構成が含まれます。また、入力LSRが、最内MPLSラベルの存続時間（TTL）を設定する必要があるかどうかなど、運用、管理、および保守（OAM）パケットを識別するために出力LSRが使用する方法を決定できるようにする構成も含まれます。出力LSRがOAMパケットを識別できるようにするには、1に設定します。 MPLS PWの障害検出の場合、このドキュメントでは、PW制御チャネルタイプ[RFC5085]が構成され、LSP Pingのサポートも構成されていることを前提としています。
A BFD session may be established for a FEC associated with an MPLS LSP. As described above, in the case of PHP or when the egress LSR distributes an explicit null label to the penultimate hop router, or next-hop label allocation, the BFD Control packet received by the egress LSR does not contain sufficient information to associate it with a BFD session. Hence, the demultiplexing MUST be done using the remote discriminator field in the received BFD Control packet. The exchange of BFD discriminators for this purpose is described in the next section.
BLSセッションは、MPLS LSPに関連付けられたFECに対して確立されます。上記のように、PHPの場合、または出力LSRが明示的なnullラベルを最後から2番目のホップルーターに配布する場合、または次ホップラベル割り当ての場合、出力LSRが受信するBFD制御パケットには、それを関連付ける十分な情報が含まれていませんBFDセッション。したがって、逆多重化は、受信したBFD制御パケットのリモート識別子フィールドを使用して実行する必要があります。この目的のためのBFD弁別子の交換については、次のセクションで説明します。
A BFD session is bootstrapped using LSP Ping. This specification describes procedures only for BFD asynchronous mode. BFD demand mode is outside the scope of this specification. Further, the use of the Echo function is outside the scope of this specification. The initiation of fault detection for a particular <MPLS LSP, FEC> combination results in the exchange of LSP Ping Echo request and Echo reply packets, in the ping mode, between the ingress and egress LSRs for that <MPLS LSP, FEC>. To establish a BFD session, an LSP Ping Echo request message MUST carry the local discriminator assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR.
BFDセッションは、LSP Pingを使用してブートストラップされます。この仕様では、BFD非同期モードのみの手順について説明します。 BFDデマンドモードは、この仕様の範囲外です。さらに、エコー関数の使用はこの仕様の範囲外です。特定の<MPLS LSP、FEC>の組み合わせの障害検出が開始されると、pingモードで、その<MPLS LSP、FEC>の入力LSRと出力LSRの間で、LSP pingエコー要求パケットとエコー応答パケットが交換されます。 BFDセッションを確立するには、LSP Ping Echo要求メッセージは、BFDセッションの入力LSRによって割り当てられたローカルの弁別子を運ばなければなりません（MUST）。これは、その後、入力LSRによって送信されたBFDセッションパケットのMy Discriminatorフィールドとして使用する必要があります。
On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds. This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR.
LSP Ping Echo要求メッセージのFECの検証が成功した場合、LSP Ping Echo要求メッセージを受信すると、出力LSRはBFD制御パケットを入力LSRに送信する必要があります。このBFD制御パケットは、Your Discriminatorフィールドを、LSP Ping Echo要求メッセージの入力LSRから受信した識別子に設定する必要があります。出力LSRは、BFDセッション用に割り当てられたローカル識別子を運ぶLSP Ping Echo応答メッセージで応答する場合があります。出力LSRによって割り当てられたローカルの識別子は、出力LSRによって送信されたBFDセッションパケットのMy Discriminatorフィールドとして使用する必要があります。
The ingress LSR follows the procedures in [BFD] to send BFD Control packets to the egress LSR in response to the BFD Control packets received from the egress LSR. The BFD Control packets from the ingress to the egress LSR MUST set the local discriminator of the egress LSR, in the Your Discriminator field. The egress LSR demultiplexes the BFD session based on the received Your Discriminator field. As mentioned above, the egress LSR MUST send Control packets to the ingress LSR with the Your Discriminator field set to the local discriminator of the ingress LSR. The ingress LSR uses this to demultiplex the BFD session.
入力LSRは、[BFD]の手順に従って、出力LSRから受信したBFD制御パケットに応答して、BFD制御パケットを出力LSRに送信します。入力から出力LSRへのBFD制御パケットは、Your Discriminatorフィールドで、出力LSRのローカル識別子を設定する必要があります。出力LSRは、受信したYour Discriminatorフィールドに基づいてBFDセッションを逆多重化します。上記のように、出力LSRは制御パケットを入力LSRに送信し、Your Discriminatorフィールドを入力LSRのローカル識別子に設定する必要があります。入力LSRはこれを使用してBFDセッションを逆多重化します。
LSP Ping Echo request and Echo reply messages carry a BFD discriminator TLV for the purpose of session establishment as described above. IANA has assigned a type value of 15 to this TLV. This TLV has a length of 4. The value contains the 4-byte local discriminator that the LSR, sending the LSP Ping message, associates with the BFD session.
LSP Ping Echo要求メッセージとEcho応答メッセージは、上記のようにセッションを確立する目的でBFD弁別子TLVを伝送します。 IANAはこのTLVにタイプ値15を割り当てました。このTLVの長さは4です。この値には、LSP Pingメッセージを送信するLSRがBFDセッションに関連付ける4バイトのローカル識別子が含まれます。
If the BFD session is not in UP state, the periodic LSP Ping Echo request messages MUST include the BFD Discriminator TLV.
BFDセッションがUP状態でない場合、定期的なLSP Ping Echo要求メッセージにはBFD Discriminator TLVを含める必要があります。
BFD Control packets sent by the ingress LSR MUST be encapsulated in the MPLS label stack that corresponds to the FEC for which fault detection is being performed. If the label stack has a depth greater than one, the TTL of the inner MPLS label MAY be set to 1. This may be necessary for certain FECs to enable the egress LSR's control plane to receive the packet [RFC4379]. For MPLS PWs, alternatively, the presence of a fault detection message may be indicated by setting a bit in the control word [RFC5085].
入力LSRによって送信されたBFD制御パケットは、障害検出が実行されているFECに対応するMPLSラベルスタックにカプセル化される必要があります。ラベルスタックの深さが1より大きい場合、内部MPLSラベルのTTLを1に設定できます（MAY）。これは、特定のFECが出力LSRのコントロールプレーンがパケットを受信できるようにするために必要になる場合があります[RFC4379]。あるいは、MPLS PWの場合、制御ワード[RFC5085]にビットを設定することで、障害検出メッセージの存在を示すことができます。
The BFD Control packet sent by the ingress LSR MUST be a UDP packet with a well-known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. The source IP address is a routable address of the sender. The destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following exception. If the FEC is an LDP IP FEC, the ingress LSR may discover multiple alternate paths to the egress LSR for this FEC using LSP Ping traceroute. In this case, the destination IP address, used in a BFD session established for one such alternate path, is the address in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 discovered by LSP Ping traceroute [RFC4379] to exercise that particular alternate path.
入力LSRによって送信されるBFD制御パケットは、既知の宛先ポート3784 [BFD-IP]と[BFD-IP]の手順に従って送信者によって割り当てられた送信元ポートを持つUDPパケットでなければなりません（MUST）。送信元IPアドレスは、送信者のルーティング可能なアドレスです。宛先IPアドレスは、IPv4の場合は127/8の範囲から、IPv6の場合は0：0：0：0：0：FFFF：7F00 / 104の範囲からランダムに選択する必要があります。ただし、次の例外があります。 FECがLDP IP FECである場合、入力LSRは、LSP Ping tracerouteを使用して、このFECの出力LSRへの複数の代替パスを検出できます。この場合、そのような代替パスの1つに対して確立されたBFDセッションで使用される宛先IPアドレスは、IPv4の場合は127/8の範囲のアドレス、またはIPv4の場合は0：0：0：0：0：FFFF：7F00 / 104の範囲のアドレスです。 LSP Ping traceroute [RFC4379]によって特定の代替パスを実行するために発見されたIPv6。
The motivation for using the address range 127/8 is the same as specified in Section 2.1 of [RFC4379]. This is an exception to the behavior defined in [RFC1122].
アドレス範囲127/8を使用する動機は、[RFC4379]のセクション2.1で指定されているものと同じです。これは、[RFC1122]で定義されている動作の例外です。
The IP TTL or hop limit MUST be set to 1 [RFC4379].
IP TTLまたはホップ制限は1に設定する必要があります[RFC4379]。
BFD Control packets sent by the egress LSR are UDP packets. The source IP address is a routable address of the replier.
出力LSRによって送信されるBFD制御パケットはUDPパケットです。送信元IPアドレスは、返信者のルーティング可能なアドレスです。
The BFD Control packet sent by the egress LSR to the ingress LSR MAY be routed based on the destination IP address as per the procedures in [BFD-MHOP]. If this is the case, the destination IP address MUST be set to the source IP address of the LSP Ping Echo request message, received by the egress LSR from the ingress LSR.
出力LSRから入力LSRに送信されたBFD制御パケットは、[BFD-MHOP]の手順に従って宛先IPアドレスに基づいてルーティングされる場合があります。この場合、宛先IPアドレスは、入力LSRから出力LSRによって受信されたLSP Ping Echo要求メッセージのソースIPアドレスに設定する必要があります。
Or the BFD Control packet sent by the egress LSR to the ingress LSR MAY be encapsulated in an MPLS label stack. In this case, the presence of the fault detection message is indicated as described above. This may be the case if the FEC for which the fault detection is being performed corresponds to a bidirectional LSP or an MPLS PW. This may also be the case when there is a return LSP from the egress LSR to the ingress LSR. In this case, the destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6.
または、出力LSRから入力LSRに送信されるBFD制御パケットは、MPLSラベルスタックにカプセル化される場合があります。この場合、前述のように、障害検出メッセージの存在が示されます。これは、障害検出が実行されているFECが双方向LSPまたはMPLS PWに対応している場合に当てはまります。これは、出力LSRから入力LSRへの戻りLSPがある場合にも当てはまります。この場合、宛先IPアドレスは、IPv4の場合は127/8の範囲から、IPv6の場合は0：0：0：0：0：FFFF：7F00 / 104の範囲からランダムに選択する必要があります。
The BFD Control packet sent by the egress LSR MUST have a well-known destination port 4784, if it is routed [BFD-MHOP], or it MUST have a well-known destination port 3784 [BFD-IP] if it is encapsulated in a MPLS label stack. The source port MUST be assigned by the egress LSR as per the procedures in [BFD-IP].
出力LSRによって送信されたBFD制御パケットは、ルーティング[BFD-MHOP]の場合、既知の宛先ポート4784を持つ必要があります。または、カプセル化されている場合、既知の宛先ポート3784 [BFD-IP]を持つ必要があります。 MPLSラベルスタック。送信元ポートは、[BFD-IP]の手順に従って、出力LSRによって割り当てられる必要があります。
Note that once the BFD session for the MPLS LSP is UP, either end of the BFD session MUST NOT change the source IP address and the local discriminator values of the BFD Control packets it generates, unless it first brings down the session. This implies that an LSR MUST ignore BFD packets for a given session, demultiplexed using the received Your Discriminator field, if the session is in UP state and if the My Discriminator or the Source IP address fields of the received packet do not match the values associated with the session.
MPLS LSPのBFDセッションがいったんUPになると、BFDセッションのどちらの端も、最初にセッションを停止しない限り、生成するBFD制御パケットのソースIPアドレスとローカル識別子を変更してはならないことに注意してください。これは、セッションがUP状態であり、受信したパケットのMy DiscriminatorまたはSource IPアドレスフィールドが関連付けられた値と一致しない場合、LSRは、受信したYour Discriminatorフィールドを使用して逆多重化された特定のセッションのBFDパケットを無視する必要があることを意味しますセッションで。
Security considerations discussed in [BFD], [BFD-MHOP], and [RFC4379] apply to this document. For BFD Control packets sent by the ingress LSR or when the BFD Control packet sent by the egress LSR are encapsulated in an MPLS label stack, MPLS security considerations apply. These are discussed in [MPLS-SEC]. When BFD Control packets sent by the egress LSR are routed, the authentication considerations discussed in [BFD-MHOP] should be followed.
[BFD]、[BFD-MHOP]、および[RFC4379]で説明されているセキュリティの考慮事項がこのドキュメントに適用されます。入力LSRによって送信されたBFD制御パケットの場合、または出力LSRによって送信されたBFD制御パケットがMPLSラベルスタックにカプセル化される場合、MPLSのセキュリティに関する考慮事項が適用されます。これらについては、[MPLS-SEC]で説明されています。出力LSRによって送信されたBFD制御パケットがルーティングされる場合、[BFD-MHOP]で説明されている認証の考慮事項に従う必要があります。
This document introduces a BFD discriminator TLV in LSP Ping. The BFD Discriminator has been assigned a value of 15 from the LSP Ping TLVs and sub-TLVs registry maintained by IANA.
このドキュメントでは、LSP PingのBFD弁別子TLVを紹介します。 BFD Discriminatorには、IANAによって維持されるLSP Ping TLVおよびサブTLVレジストリから値15が割り当てられています。
We would like to thank Yakov Rekhter, Dave Katz, and Ina Minei for contributing to the discussions that formed the basis of this document and for their comments. Thanks to Dimitri Papadimitriou for his comments and review. Thanks to Carlos Pignataro for his comments and review.
この文書の基礎となった議論に貢献してくれたYakov Rekhter、Dave Katz、およびIna Mineiに感謝し、コメントを寄せてください。 Dimitri Papadimitriouのコメントとレビューに感謝します。彼のコメントとレビューをしてくれたCarlos Pignataroに感謝します。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[BFD] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection」、RFC 5880、2010年6月。
[BFD-IP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-IP] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、2010年6月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[BFD-MHOP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[BFD-MHOP] Katz、D。およびD. Ward、「マルチホップパスの双方向転送検出（BFD）」、RFC 5883、2010年6月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T.、Ed。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、2007年12月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、編、スワロー、G。、編、およびA.アトラス、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[L2-VPN] Kompella, K., Leelanivas, M., Vohra, Q., Achirica, J., Bonica, R., Cooper, D., Liljenstolpe, C., Metz, E., Ould-Brahim, H., Sargor, C., Shah, H., Srinivasan, and Z. Zhang, "Layer 2 VPNs Over Tunnels", Work in Progress, February 2003.
[L2-VPN] Kompella、K.、Leelanivas、M.、Vohra、Q.、Achirica、J.、Bonica、R.、Cooper、D.、Liljenstolpe、C.、Metz、E.、Ould-Brahim、H 。、Sargor、C.、Shah、H.、Srinivasan、およびZ. Zhang、「Layer 2 VPNs Over Tunnels」、Work in Progress、2003年2月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y。およびE. Rosen、「Carrying Label Information in BGP-4」、RFC 3107、2001年5月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operations and Management（OAM）Requirements for Multi-Protocol Label Switched（MPLS）Networks」、RFC 4377 、2006年2月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[MPLS-SEC] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、Work in Progress、2009年10月。
Authors' Addresses
著者のアドレス
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal Juniper Networks 1194いいえ。マチルダAV。サニーベール、94089彼
EMail: rahul@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
キリーティコンペラジュニパーネットワークス1194 N.マチルダアベニュー。サニーベール、カリフォルニア州94089米国
EMail: kireeti@juniper.net
Thomas D. Nadeau BT BT Centre 81 Newgate Street London EC1A 7AJ UK
トーマスD.ナドーBT BTセンター81ニューゲートストリートロンドンEC1A 7AJ英国
EMail: tom.nadeau@bt.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
George Swallow Cisco Systems、Inc. 300 Beaver Brook Road Boxborough、MA 01719 USA
EMail: swallow@cisco.com