[要約] RFC 9186は、マルチポイントネットワークにおけるプロトコル独立マルチキャスト-スパースモード(PIM-SM)の高速フェイルオーバーを、双方向フォワーディング検出(BFD)を使用して実現する方法について記述しています。この文書の目的は、ネットワークの障害発生時に迅速に切り替えることで、サービスの中断時間を最小限に抑えることです。主に、高可用性が求められる大規模配信ネットワークや、リアルタイム性が重要なアプリケーションのサポートに利用されます。

Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 9186                                      Ericsson
Category: Standards Track                                          X. Ji
ISSN: 2070-1721                                          ZTE Corporation
                                                            January 2022
        

Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks

多点線の双方向転送検出(BFD)を使用したプロトコル独立マルチキャスト - スパースモード(PIM-SM)の高速フェイルオーバー

Abstract

概要

This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document.

このドキュメントでは、マルチポイントネットワークの双方向転送検出(BFD)が、プロトコルに依存しないマルチキャストスパースモード(PIM-SM)に参加するルータに対してサブ秒のフェールオーバーを提供できる方法を指定します。ポイントツーマルチポイントBFDセッションをブートストラップするために使用されるPIM helloメッセージの拡張もこのドキュメントでも定義されています。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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 7841.

この文書はインターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9186.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9186で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2022 IETF信頼と文書の著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、この文書の公開日に有効なIETF文書(https://trustee.ietf.org/License-Info)に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。

Table of Contents

目次

   1.  Introduction
     1.1.  Conventions Used in This Document
       1.1.1.  Terminology
       1.1.2.  Requirements Language
   2.  BFD Discriminator PIM Hello Option
     2.1.  Using P2MP BFD in PIM Router Monitoring
     2.2.  P2MP BFD in PIM DR Load Balancing
     2.3.  Multipoint BFD Encapsulation
   3.  IANA Considerations
   4.  Security Considerations
   5.  References
     5.1.  Normative References
     5.2.  Informative References
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

Faster convergence in the control plane minimizes the periods of traffic loss due to the use of stale routing information, transient routing loops, and other situations that may negatively affect service data flow. Faster convergence in the control plane is beneficial to unicast and multicast routing protocols.

制御面内のより速い収束は、古いルーティング情報、過渡ルーティングループ、およびサービスデータフローに悪影響を及ぼす可能性がある他の状況の使用によるトラフィック損失の周期を最小限に抑える。コントロールプレーン内のより速い収束は、ユニキャストおよびマルチキャストルーティングプロトコルにとって有益です。

[RFC7761] is the current specification of the Protocol Independent Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. A conforming implementation of PIM-SM elects a Designated Router (DR) on each PIM-SM interface. When a group of PIM-SM nodes is connected to a shared media segment, e.g., Ethernet, the node elected as the DR acts on behalf of directly connected hosts in the context of the PIM-SM protocol. Failure of the DR impacts the quality of the multicast services it provides to directly connected hosts because the default failure detection interval for PIM-SM routers is 105 seconds.

[RFC7761] IPv4ネットワークとIPv6ネットワークのプロトコル独立マルチキャストスパースモード(PIM-SM)の現在の仕様です。PIM-SMの適合的な実装は、各PIM-SMインターフェイス上で指定ルータ(DR)を選択します。PIM-SMノードのグループが共有メディアセグメント、例えばイーサネットに接続されている場合、PIM-SMプロトコルのコンテキストでDRが直接接続されたホストに代わって行動するノードが選択されます。PIM-SMルータのデフォルトの障害検出間隔は105秒であるため、DRの故障は直接接続されているホストに提供するマルチキャストサービスの品質に影響します。

Bidirectional Forwarding Detection (BFD) [RFC5880] was originally defined to detect a failure of a point-to-point (P2P) path, single hop [RFC5881], or multihop [RFC5883]. In some PIM-SM deployments, a P2P BFD can be used to detect a failure and enable faster failover. [RFC8562] extends the BFD base specification [RFC5880] for multipoint and multicast networks, which matches the deployment scenarios for PIM-SM over a LAN segment. A BFD system in a point-to-multipoint (P2MP) environment that transmits BFD Control messages using the BFD Demand mode [RFC5880] creates less BFD state than the Asynchronous mode. P2MP BFD can enable faster detection of PIM-SM router failure compared to PIM-SM without BFD and thus minimizes multicast service disruption. The monitored PIM-SM router acts as the head and other routers act as tails of a P2MP BFD session. This document defines the monitoring of a PIM-SM router using P2MP BFD. This document also defines the extension to PIM-SM [RFC7761] to bootstrap a PIM-SM router to join in the P2MP BFD session over a shared media segment.

双方向フォワーディング検出(BFD)[RFC5880]は元々ポイントツーポイント(P2P)パスの障害、単一ホップ[RFC5881]、またはマルチホップ[RFC5883]を検出するように定義されました。いくつかのPIM-SMの展開では、P2P BFDは障害を検出し、より高速なフェイルオーバーを有効に使用することができます。 [RFC8562]はLANセグメント上にPIM-SMの展開シナリオと一致する多マルチキャストネットワークのためのBFDベース仕様[RFC5880]を、延びています。 BFDデマンドモード[RFC5880]を使用して送信BFD制御メッセージは非同期モードよりもBFD状態を作成するポイントツーマルチポイント(P2MP)環境におけるA BFDシステム。 P2MP BFDが速くBFD無しPIM-SMと比較してPIM-SMルータ故障の検出を可能にし、従って、マルチキャストサービスの中断を最小限に抑えることができます。頭と他のルータは、P2MP BFDセッションの尾として機能として動作するルータPIM-SMを監視しました。この文書では、P2MP BFDを使用して、ルータPIM-SMの監視を定義します。この文書は、共有メディアセグメント上P2MP BFDセッションに参加するPIM-SMルータをブートストラップするPIM-SM [RFC7761]の拡張機能を定義します。

1.1. Conventions Used in This Document
1.1. この文書で使用されている規約
1.1.1. Terminology
1.1.1. 用語

This document uses terminology defined in [RFC5880], [RFC8562], and [RFC7761]. Familiarity with these specifications and the terminology used is expected.

この文書では、[RFC5880]、[RFC8562]、[RFC7761]で定義されている用語を使用しています。これらの仕様と使用されている用語に精通していることが予想されます。

1.1.2. Requirements Language
1.1.2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. BFD Discriminator PIM Hello Option
2. BFD弁別器PIMこんにちはオプション

Figure 1 displays the new optional BFD Discriminator PIM Hello Option to bootstrap a tail of the P2MP BFD session:

図1は、P2MP BFDセッションの末尾をブートストラップするための新しいオプションのBFD識別子PIM Helloオプションを表示します。

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          OptionType           |         OptionLength          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       HeadDiscriminator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 1: BFD Discriminator PIM Hello Option

図1:BFD弁別器PIMこんにちはオプション

where new fields are interpreted as:

新しいフィールドが次のように解釈される場合

OptionType: 39

OptionType:39

OptionLength: MUST be set to 4.

OptionLength:4に設定する必要があります。

HeadDiscriminator: the 4-octet field MUST be included in the BFD Discriminator PIM-SM Hello Option. The value MUST NOT be zero. It equals the value of My Discriminator [RFC5880] allocated by the head.

HEADDISCRIMINATOR:4オクテットフィールドは、BFD弁別器PIM-SM Helloオプションに含める必要があります。値はゼロにしてはいけません。それは頭のそばに割り当てられた私の識別子[RFC5880]の値と同じです。

If the value of the OptionLength field is not equal to 4, the BFD Discriminator PIM Hello Option is considered malformed, and the receiver MUST stop processing PIM Hello Options. If the value of the HeadDiscriminator field equals zero, then the BFD Discriminator PIM Hello Option MUST be considered invalid, and the receiver MUST ignore it. The receiver SHOULD log a notification regarding the malformed or invalid BFD Discriminator Hello Option under the control of a throttling logging mechanism.

OptionLengthフィールドの値が4に等しくない場合、BFD識別子PIM Helloオプションは不正なことと見なされ、受信機はPIM Helloオプションの処理を停止しなければなりません。HEADISCRIMINATORフィールドの値がゼロに等しい場合、BFD識別子PIM HELLOオプションは無効と見なされなければならず、受信機はそれを無視する必要があります。受信機は、スロットルロギングメカニズムの制御下で、不正なBFD識別子helloオプションに関する通知を記録する必要があります。

2.1. Using P2MP BFD in PIM Router Monitoring
2.1. PIMルータ監視でP2MP BFDを使用する

If the head is no longer serving the function that prompted it to be monitored, then it MUST cease including the BFD Discriminator PIM Hello Option in its PIM Hello message, and it SHOULD shut down the BFD session following the procedures described in [RFC8562], Section 5.9.

ヘッドが監視されるように促された機能を提供していない場合は、PIM HelloメッセージでBFD識別子PIM Helloオプションを含めることを停止し、[RFC8562]に記載されている手順に従ってBFDセッションをシャットダウンする必要があります。セクション5.9。

The head MUST create a BFD session of type MultipointHead [RFC8562]. Note that any PIM-SM router, regardless of its role, MAY become a head of a P2MP BFD session. To control the volume of BFD Control traffic on a shared media segment, an operator should carefully select PIM-SM routers configured as a head of a P2MP BFD session. The head MUST include the BFD Discriminator PIM Hello Option in its PIM Hello messages.

HEADはタイプマルチポイントヘッドのBFDセッションを作成する必要があります[RFC8562]。その役割に関係なく、任意のPIM-SMルータがP2MP BFDセッションの先頭になる可能性があることに注意してください。共有メディアセグメントでBFD制御トラフィックのボリュームを制御するために、オペレータはP2MP BFDセッションの先頭として設定されているPIM-SMルータを慎重に選択してください。ヘッドには、PIM HelloメッセージにBFD弁別器PIM Helloオプションを含める必要があります。

A PIM-SM router that is configured to monitor the head by using P2MP BFD is referred to throughout this document as a "tail". When such a tail receives a PIM Hello packet with the BFD Discriminator PIM Hello Option, the tail MAY create a P2MP BFD session of type MultipointTail, as defined in [RFC8562].

P2MP BFDを使用してヘッドを監視するように構成されているPIM-SMルータは、この文書全体を通して「テール」と呼ばれます。そのような末尾がBFD弁別器PIM Helloオプションを使用してPIM Helloパケットを受信すると、[RFC8562]で定義されているように、テールはマルチポイントタイプのP2MP BFDセッションを作成できます。

The node that includes the BFD Discriminator PIM Hello Option transmits BFD Control packets periodically. For the tail to correctly demultiplex BFD [RFC8562], the source address and My Discriminator of the BFD packets MUST be the same as the source address and the HeadDiscriminator, respectively, of the PIM Hello message. If that is not the case, the tail BFD node would not be able to monitor the state of the PIM-SM node -- that is, the head of the P2MP BFD session -- though the regular PIM-SM mechanisms remain fully operational.

BFD弁別器PIM Helloオプションを含むノードは、BFD制御パケットを定期的に送信する。テールがデマルチプレックスBFD [RFC8562]、BFDパケットの送信元アドレスとマイ識別子は、それぞれPIM HelloメッセージのソースアドレスとHEADDISCRIMINATORと同じでなければなりません。そうでない場合、テールBFDノードはPIM-SMノードの状態を監視できません。つまり、P2MP BFDセッションのヘッドですが、通常のPIM-SMメカニズムは完全に動作可能です。

If the tail detects a MultipointHead failure [RFC8562], it MUST delete the corresponding neighbor state and follow procedures defined in [RFC7761] for the DR and additional neighbor state deletion after the neighbor timeout expires.

末尾がマルチポイントヘッドの障害を検出した場合[RFC8562]は、識別タイムアウトが期限切れになった後にDRおよび追加のネイバー状態の削除の[RFC7761]で定義されている手順に従ってください。

If the head ceases to include the BFD Discriminator PIM Hello Option in its PIM Hello message, the tail SHOULD close the corresponding MultipointTail BFD session without affecting the PIM state in any way. Thus, the tail stops using BFD to monitor the head and reverts to the procedures defined in [RFC7761].

ヘッドがそのPIM HelloメッセージでBFD弁別器PIM Helloオプションを含めるのを停止した場合、末尾はPIM状態に影響を与えることなく対応するマルチポイントテイルBFDセッションを閉じる必要があります。したがって、テールはBFDを使用してヘッドを監視し、[RFC7761]で定義されている手順に戻ります。

2.2. P2MP BFD in PIM DR Load Balancing
2.2. PIM DRロードバランシングのP2MP BFD
   [RFC8775] specifies the PIM Designated Router Load-Balancing (DRLB)
   functionality.  Any PIM router that advertises the DR Load-Balancing
   Capability (DRLB-Cap) Hello Option can become the head of a P2MP BFD
   session, as specified in Section 2.1.  The head router
   administratively sets the bfd.SessionState to Up in the
   MultipointHead session [RFC8562] only if it is a Group Designated
   Router (GDR) Candidate, as specified in Sections 5.5 and 5.6 of
   [RFC8775].  If the router is no longer the GDR, then it MUST shut
   down following the procedures described in [RFC8562], Section 5.9.
   For each GDR Candidate that includes the BFD Discriminator Option in
   its PIM Hello, the PIM DR MUST create a MultipointTail session
   [RFC8562].  PIM DR demultiplexes BFD sessions based on the value of
   the My Discriminator field and the source IP address.  If PIM DR
   detects a failure of one of the sessions, it MUST remove that router
   from the GDR Candidate list and immediately transmit a new DRLB-List
   option.
        
2.3. Multipoint BFD Encapsulation
2.3. マルチポイントBFDカプセル化

The MultipointHead of a P2MP BFD session when transmitting BFD Control packets:

BFD制御パケットを送信するときのP2MP BFDセッションのマルチポイントヘッド:

* MUST set the TTL or Hop Limit value to 255 ([RFC5881], Section 5). Similarly, all received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255, and

* TTLまたはホップ制限値を255に設定する必要があります([RFC5881]、セクション5)。同様に、受信されたTTLまたはホップ制限が255に等しくない場合、セッションに逆多重化されているすべての受信BFD制御パケットは破棄されなければならず、

* MUST use the group address ALL-PIM-ROUTERS ("224.0.0.13" for IPv4 and "ff02::d" for IPv6) as the destination IP address.

* 宛先IPアドレスとして、グループアドレスALL-PIMルーター(IPv4、IPv4、 "FF02 :: D"の "224.0.0.13"を使用する必要があります。

3. IANA Considerations
3. IANAの考慮事項

IANA has allocated a new OptionType value in the "PIM-Hello Options" registry according to Table 1:

IANAは、表1に従って「PIM-Helloオプション」レジストリに新しいOptionType値を割り当てました。

         +=======+========+==========================+===========+
         | Value | Length | Name                     | Reference |
         +=======+========+==========================+===========+
         | 39    | 4      | BFD Discriminator Option | RFC 9186  |
         +-------+--------+--------------------------+-----------+
        

Table 1: BFD Discriminator Option Type

表1:BFD弁別器オプションタイプ

4. Security Considerations
4. セキュリティに関する考慮事項

This document defines a way to accelerate detection of a failure that affects PIM functionality by using BFD. The operation of either protocol is not changed.

この文書は、BFDを使用してPIM機能に影響を与える障害の検出を高速化する方法を定義しています。どちらのプロトコルの動作も変更されません。

The security considerations discussed in [RFC5880], [RFC5881], [RFC7761], [RFC8562], and [RFC8775] apply to this document.

[RFC5880]、[RFC5881]、[RFC7761]、[RFC8562]、[RFC8562]、[RFC8775]、[RFC8775]、[RFC8575]、[RFC8562]、[RFC8775]で説明しています。

5. References
5. 参考文献
5.1. Normative References
5.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.

[RFC5880] Katz、D.およびD.ワード、「双方向転送検出(BFD)」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。

[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.

[RFC5881] Katz、D.およびD. Ward、IPv4およびIPv6(シングルホップ)の双方向転送検出(BFD)、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<https://www.rfc-編集者.ORG / INFO / RFC5881>。

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.

[RFC7761] Fenner、B、Handley、M.、Holbrook、H.、Kouvelas、I。、Parekh、R.、Zhang、Z.、L.Zheng、 "プロトコル独立マルチキャスト - スパースモード(PIM-SM):プロトコル仕様(改訂) "、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https://www.rfc-editor.org/info/rfc7761>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/RFC8174>。

[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, <https://www.rfc-editor.org/info/rfc8562>.

[RFC8562] Katz、D.、Ward、D.、Pallagatti、S.、Ed。、およびG. Mirsky、Ed。、「多地点ネットワークのための双方向転送検出(BFD)」、RFC 8562、DOI 10.17487 / RFC8562、4月2019年、<https://www.rfc-editor.org/info/rfc8562>。

[RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., and A. Green, "PIM Designated Router Load Balancing", RFC 8775, DOI 10.17487/RFC8775, April 2020, <https://www.rfc-editor.org/info/rfc8775>.

[RFC8775] CAI、Y、OU、H。、H.、Vallepalli、S.、Mishra、M.、Venaas、S.、およびA.緑色、「PIM指定ルーター負荷分散」、RFC 8775、DOI 10.17487 / RFC8775、4月2020、<https://www.rfc-editor.org/info/rfc8775>。

5.2. Informative References
5.2. 参考引用

[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, <https://www.rfc-editor.org/info/rfc5883>.

[RFC5883] Katz、D.およびD.ワード、「マルチホップパスの双方向転送検出(BFD)」、RFC 5883、DOI 10.17487 / RFC5883、2010年6月、<https://www.rfc-editor.org/info/RFC5883>。

Acknowledgments

謝辞

The authors cannot say enough to express their appreciation of the comments and suggestions that were received from Stig Venaas. The authors also greatly appreciate the comments and suggestions by Alvaro Retana that improved the clarity of this document.

著者らは、Stig Venaasから受け取ったコメントや提案の感謝を表現するのに十分なことはできません。著者らはまた、この文書の明快さを改善したAlvaro retanaによるコメントや提案を大いに感謝します。

Authors' Addresses

著者の住所

Greg Mirsky Ericsson

Greg Mirsky Ericsson.

   Email: gregimirsky@gmail.com
        

Xiaoli Ji ZTE Corporation Yuhuatai District No. 50 Software Avenue Nanjing China

Xiaoli Ji Zte Corporation Yuhuatai District No. 50 Software Avenue Nanjing China

   Email: ji.xiaoli@zte.com.cn