[要約] RFC 8364は、PIM Flooding Mechanism（PFM）とSource Discovery（SD）に関する標準化されたプロトコル仕様です。このRFCの目的は、マルチキャストトラフィックの効率的な配信と、ソースの自動検出を実現することです。
Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 8364 S. Venaas
Category: Experimental Cisco Systems, Inc.
ISSN: 2070-1721 M. Brig
Aegis BMD Program Office
A. Jonasson
FMV
March 2018
PIM Flooding Mechanism (PFM) and Source Discovery (SD)
PIMフラッディングメカニズム（PFM）およびソース検出（SD）
Abstract
概要
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.
プロトコル非依存マルチキャスト-スパースモード（PIM-SM）は、ランデブーポイント（RP）と共有ツリーを使用して、新しいソースからマルチキャストパケットを転送します。ラストホップルーター（LHR）が新しいソースからパケットを受信すると、最適な転送のためにソースの最短パスツリー（SPT）に参加できます。このドキュメントでは、PIMレジスタ、RP、または共有ツリーを必要とせずにPIM-SMをサポートする方法を提供する新しいメカニズムを定義します。マルチキャストソース情報は、新しい汎用PIMフラッディングメカニズム（PFM）を使用してマルチキャストドメイン全体にフラッディングされます。これにより、LHRは初期データパケットを受信せずに新しいソースについて学習できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8364.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8364で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and Deployment Experiences . . . . . . . . . . . . . 5
3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5
3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9
3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10
4. Distributing SG Mappings . . . . . . . . . . . . . . . . . . 11
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 11
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 12
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 13
4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC7761] uses a Rendezvous Point (RP) and shared trees to forward multicast packets to Last-Hop Routers (LHRs). After the first packet is received by an LHR, the source of the multicast stream is learned and the Shortest Path Tree (SPT) can be joined. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM flooding mechanism. By removing the need for RPs and shared trees, the PIM-SM procedures are simplified, thus improving router operations and management, and making the protocol more robust. Also, the data packets are only sent on the SPTs, providing optimal forwarding.
プロトコル非依存マルチキャスト-スパースモード（PIM-SM）[RFC7761]は、ランデブーポイント（RP）と共有ツリーを使用して、マルチキャストパケットをラストホップルーター（LHR）に転送します。 LHRが最初のパケットを受信すると、マルチキャストストリームのソースが学習され、Shortest Path Tree（SPT）に参加できます。このドキュメントでは、PIMレジスタ、RP、または共有ツリーを必要とせずにPIM-SMをサポートする方法を提供する新しいメカニズムを定義します。マルチキャストソース情報は、新しい汎用PIMフラッディングメカニズムを使用して、マルチキャストドメイン全体にフラッディングされます。 RPおよび共有ツリーの必要性をなくすことにより、PIM-SMの手順が簡略化され、ルーターの操作と管理が改善され、プロトコルがより堅牢になります。また、データパケットはSPTでのみ送信され、最適な転送を提供します。
This mechanism has some similarities to Protocol Independent Multicast - Dense Mode (PIM-DM) with its State-Refresh signaling [RFC3973], except that there is no initial flooding of data packets for new sources. It provides the traffic efficiency of PIM-SM, while being as easy to deploy as PIM-DM. The downside is that it cannot provide forwarding of initial packets from a new source, see Section 4.4. PIM-DM is very different from PIM-SM; it's not as mature, it is categorized as Experimental not an Internet Standard, and there are only a few implementations of it. The solution in this document consists of a lightweight source discovery mechanism on top of the Source-Specific Multicast (SSM) [RFC4607] parts of PIM-SM. It is feasible to implement only a subset of PIM-SM to provide SSM support and, in addition, implement the mechanism in this document to offer a source discovery mechanism for applications that do not provide their own source discovery.
このメカニズムは、State-Refreshシグナリング[RFC3973]を使用したProtocol Independent Multicast-Dense Mode（PIM-DM）といくつかの類似点がありますが、新しいソースへのデータパケットの初期フラッディングがない点が異なります。 PIM-SMのトラフィック効率を提供すると同時に、PIM-DMと同じくらい簡単に展開できます。欠点は、新しいソースからの初期パケットの転送を提供できないことです。セクション4.4を参照してください。 PIM-DMはPIM-SMとは大きく異なります。それは成熟しておらず、インターネット標準ではなく実験的として分類されており、その実装はほんのわずかです。このドキュメントのソリューションは、PIM-SMのSource-Specific Multicast（SSM）[RFC4607]部分に基づく軽量のソース検出メカニズムで構成されています。 PIM-SMのサブセットのみを実装してSSMサポートを提供し、さらにこのドキュメントのメカニズムを実装して、独自のソースディスカバリを提供しないアプリケーションにソースディスカバリメカニズムを提供することが可能です。
This document defines a generic flooding mechanism for distributing information throughout a PIM domain. While the forwarding rules are largely similar to the Bootstrap Router (BSR) mechanism [RFC5059], any router can originate information; this allows for flooding of any kind of information. Each message contains one or more pieces of information encoded as TLVs. This document defines one TLV used for distributing information about active multicast sources. Other documents may define additional TLVs.
このドキュメントでは、PIMドメイン全体に情報を配信するための一般的なフラッディングメカニズムを定義しています。転送ルールはブートストラップルーター（BSR）メカニズム[RFC5059]とほぼ同じですが、どのルーターも情報を発信できます。これにより、あらゆる種類の情報のフラッディングが可能になります。各メッセージには、TLVとしてエンコードされた1つ以上の情報が含まれています。このドキュメントでは、アクティブなマルチキャストソースに関する情報を配信するために使用される1つのTLVを定義します。その他のドキュメントでは、追加のTLVが定義されている場合があります。
Note that this document is an Experimental RFC. While the flooding mechanism is largely similar to BSR, there are some concerns about scale as there can be multiple routers distributing information, and potentially a larger amount of data that needs to be processed and stored. Distributing knowledge of active sources in this way is new; there are some concerns, mainly regarding potentially large amounts of source states that need to be distributed. While there has been some testing in the field, we need to learn more about the forwarding efficiency, both the amount of processing per router, propagation delay, and the amount of state that can be distributed. In particular, how many active sources one can support without consuming too many resources. There are also parameters, see Section 5, that can be tuned regarding how frequently information is distributed. It is not clear what parameters are useful for different types of networks.
このドキュメントは試験的なRFCであることに注意してください。フラッディングメカニズムはBSRとほぼ同様ですが、情報を配信する複数のルーターが存在する可能性があり、処理および保存が必要な大量のデータが存在する可能性があるため、規模に関する懸念があります。この方法でアクティブソースの知識を配布することは新しいです。いくつかの懸念があり、主に配布する必要のある潜在的に大量のソース状態に関するものです。いくつかのフィールドでのテストが行われていますが、転送効率、ルーターごとの処理量、伝播遅延、および分散可能な状態の量の両方についてさらに学ぶ必要があります。特に、多くのリソースを消費せずにサポートできるアクティブなソースの数。セクション5を参照して、情報の配信頻度に関して調整できるパラメーターもあります。さまざまなタイプのネットワークにどのパラメータが役立つかは明らかではありません。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
RP: Rendezvous Point
RP：ランデブーポイント
BSR: Bootstrap Router
BSR：ブートストラップルーター
RPF: Reverse Path Forwarding
RPF：リバースパス転送
SPT: Shortest Path Tree
SPT：最短パスツリー
FHR: First-Hop Router, directly connected to the source
FHR：ソースに直接接続されたファーストホップルーター
LHR: Last-Hop Router, directly connected to the receiver
LHR：レシーバーに直接接続されたラストホップルーター
PFM: PIM Flooding Mechanism
PFM：PIMフラッディングメカニズム
PFM-SD: PFM Source Discovery
PFM-SD：PFMソース検出
SG Mapping: Multicast source group (SG) mapping
SGマッピング：マルチキャストソースグループ（SG）マッピング
A prototype of this specification has been implemented, and there has been some limited testing in the field. The prototype was tested in a network with low-bandwidth radio links. The network has frequent topology changes, including frequent link or router failures. Previously existing mechanisms were tested (for example, PIM-SM and PIM-DM).
この仕様のプロトタイプが実装されており、フィールドでの限定的なテストがいくつか行われています。プロトタイプは、低帯域幅の無線リンクを備えたネットワークでテストされました。ネットワークは、頻繁なリンクまたはルーターの障害を含む、頻繁なトポロジー変更を持っています。以前から存在するメカニズムがテストされました（たとえば、PIM-SMおよびPIM-DM）。
With PIM-SM, the existing RP election mechanisms were found to be too slow. With PIM-DM, issues were observed with new multicast sources starving low-bandwidth links even when there were no receivers; in some cases, so much so that there was no bandwidth left for prune messages.
PIM-SMでは、既存のRP選出メカニズムが遅すぎることが判明しました。 PIM-DMを使用すると、レシーバーがない場合でも、新しいマルチキャストソースが低帯域幅リンクを不足させる問題が発生しました。場合によっては、プルーンメッセージ用の帯域幅がなくなるほど多くの場合があります。
For the PFM-SD prototype tests, all routers were configured to send PFM-SD for the directly connected source and to cache received announcements. Applications such as SIP with multicast subscriber discovery, multicast voice conferencing, position tracking, and NTP were successfully tested. The tests went quite well. Packets were rerouted as needed; there was no unnecessary forwarding of packets. Ease of configuration was seen as a plus.
PFM-SDプロトタイプテストの場合、すべてのルーターは、直接接続されたソースのPFM-SDを送信し、受信したアナウンスをキャッシュするように構成されました。マルチキャストサブスクライバディスカバリを使用したSIP、マルチキャスト音声会議、位置追跡、NTPなどのアプリケーションは、正常にテストされました。テストはかなりうまくいきました。パケットは必要に応じて再ルーティングされました。パケットの不必要な転送はありませんでした。構成の容易さはプラスと見なされました。
The Bootstrap Router (BSR) mechanism [RFC5059] is a commonly used mechanism for distributing dynamic Group-to-RP mappings in PIM. It is responsible for flooding information about such mappings throughout a PIM domain so that all routers in the domain can have the same information. BSR, as defined, is only able to distribute Group-to-RP mappings. This document defines a more generic mechanism that can flood any kind of information. Administrative boundaries, see Section 3.2, may be configured to limit to which parts of a network the information is flooded.
ブートストラップルーター（BSR）メカニズム[RFC5059]は、PIMで動的なグループからRPへのマッピングを配布するために一般的に使用されるメカニズムです。ドメイン内のすべてのルーターが同じ情報を持つことができるように、PIMドメイン全体にそのようなマッピングに関する情報をフラッディングする責任があります。 BSRは、定義されているように、グループからRPへのマッピングのみを配布できます。このドキュメントでは、あらゆる種類の情報をフラッディングする可能性のある、より一般的なメカニズムを定義しています。管理上の境界（セクション3.2を参照）は、情報が氾濫するネットワークの部分に制限するように構成できます。
The forwarding rules are identical to BSR, except that one can control whether routers should forward unsupported data types. For some types of information, it is quite useful that it can be distributed without all routers having to support the particular type, while there may also be types where it is necessary for every single router to support it. The mechanism includes an originator address that is used for RPF checking to restrict the flooding and prevent loops, just like BSR. Like BSR, messages are forwarded hop-by-hop; the messages are link-local, and each router will process and resend the messages. Note that there is no equivalent to the BSR election mechanism; there can be multiple originators. This mechanism is named the PIM Flooding Mechanism (PFM).
転送ルールはBSRと同じですが、ルーターがサポートされていないデータタイプを転送するかどうかを制御できます。一部のタイプの情報については、すべてのルーターが特定のタイプをサポートしなくても配布できると非常に便利ですが、すべてのルーターがそれをサポートする必要があるタイプもあるかもしれません。このメカニズムには、BSRと同様に、RPFチェックでフラッディングを制限してループを防止するために使用される発信元アドレスが含まれています。 BSRと同様に、メッセージはホップバイホップで転送されます。メッセージはリンクローカルであり、各ルーターがメッセージを処理して再送信します。 BSR選出メカニズムに相当するものがないことに注意してください。複数のオリジネーターが存在する可能性があります。このメカニズムは、PIMフラッディングメカニズム（PFM）と呼ばれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
|T| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, and Checksum: As specified in [RFC7761].
PIMバージョン、予約済み、およびチェックサム：[RFC7761]で指定されています。
Type: PIM Message Type. Value 12 for a PFM message.
タイプ：PIMメッセージタイプ。 PFMメッセージの値12。
[N]o-Forward bit: When set, this bit means that the PFM message is not to be forwarded. This bit is defined to prevent Bootstrap message forwarding in [RFC5059].
[N] o-Forwardビット：設定されている場合、このビットはPFMメッセージが転送されないことを意味します。このビットは、[RFC5059]でBootstrapメッセージの転送を防ぐために定義されています。
Originator Address: The address of the router that originated the message. This can be any address assigned to the originating router, but it MUST be routable in the domain to allow successful forwarding. The format for this address is given in the Encoded-Unicast address in [RFC7761].
発信元アドレス：メッセージを発信したルーターのアドレス。これは、発信元ルーターに割り当てられた任意のアドレスにすることができますが、正常に転送できるようにドメイン内でルーティング可能でなければなりません。このアドレスのフォーマットは[RFC7761]のエンコードされたユニキャストアドレスで与えられます。
[T]ransitive bit: Each TLV in the message includes a bit called the "Transitive" bit that controls whether the TLV is forwarded by routers that do not support the given type. See Section 3.4.2.
[T] ransitiveビット：メッセージ内の各TLVには、「Transitive」ビットと呼ばれるビットが含まれており、指定されたタイプをサポートしないルーターによってTLVが転送されるかどうかを制御します。セクション3.4.2を参照してください。
Type 1..n: A message contains one or more TLVs, in this case n TLVs. The Type specifies what kind of information is in the Value. The Type range is from 0 to 32767 (15 bits).
タイプ1..n：メッセージには1つ以上のTLV、この場合はn TLVが含まれます。 Typeは、Valueに含まれる情報の種類を指定します。タイプの範囲は0〜32767（15ビット）です。
Length 1..n: The length of the Value field in octets.
長さ1..n：オクテット単位の値フィールドの長さ。
Value 1..n: The value associated with the type and of the specified length.
値1..n：タイプおよび指定された長さの値。
PFM messages are generally forwarded hop-by-hop to all PIM routers. However, similar to BSR, one may configure administrative boundaries to limit the information to certain domains or parts of the network. Implementations MUST have a way of defining a set of interfaces on a router as administrative boundaries for all PFM messages or, optionally, for certain TLVs, allowing for different boundaries for different TLVs. Usually, one wants boundaries to be bidirectional, but an implementation MAY also provide unidirectional boundaries. When forwarding a message, a router MUST NOT send it out on an interface that is an outgoing boundary, including a bidirectional boundary, for all PFM messages. If an interface is an outgoing boundary for certain TLVs, the message MUST NOT be sent out on the interface if it is a boundary for all the TLVs in the message. Otherwise, the router MUST remove all the boundary TLVs from the message and send the message with the remaining TLVs. Also, when receiving a PFM message on an interface, the message MUST be discarded if the interface is an incoming boundary, including a bidirectional boundary, for all PFM messages. If the interface is an incoming boundary for certain TLVs, the router MUST ignore all boundary TLVs. If all the TLVs in the message are boundary TLVs, then the message is effectively ignored. Note that when forwarding an incoming message, the boundary is applied before forwarding. If the message was discarded or all the TLVs were ignored, then no message is forwarded. When a message is forwarded, it MUST NOT contain any TLVs for which the incoming interface is an incoming or bidirectional boundary.
PFMメッセージは通常、ホップバイホップですべてのPIMルーターに転送されます。ただし、BSRと同様に、管理境界を設定して、情報を特定のドメインまたはネットワークの一部に制限することができます。実装には、すべてのPFMメッセージの管理境界として、またはオプションで特定のTLVのルーター上にインターフェイスのセットを定義する方法があり、異なるTLVに異なる境界を許可する必要があります。通常、境界は双方向であることが望まれますが、実装は一方向の境界も提供する場合があります。メッセージを転送するとき、ルーターは、すべてのPFMメッセージに対して、双方向の境界を含む発信境界であるインターフェイス上でメッセージを送信してはなりません（MUST NOT）。インターフェイスが特定のTLVの発信境界である場合、それがメッセージ内のすべてのTLVの境界である場合、メッセージはインターフェイス上で送信してはなりません（MUST NOT）。それ以外の場合、ルーターはすべての境界TLVをメッセージから削除し、残りのTLVと共にメッセージを送信する必要があります。また、インターフェイスでPFMメッセージを受信するとき、インターフェイスがすべてのPFMメッセージの双方向境界を含む着信境界である場合、メッセージは破棄されなければなりません（MUST）。インターフェイスが特定のTLVの着信境界である場合、ルーターはすべての境界TLVを無視する必要があります。メッセージ内のすべてのTLVが境界TLVである場合、メッセージは事実上無視されます。着信メッセージを転送する場合、転送前に境界が適用されることに注意してください。メッセージが破棄された場合、またはすべてのTLVが無視された場合、メッセージは転送されません。メッセージが転送されるとき、着信インターフェースが着信または双方向の境界であるTLVが含まれていてはなりません（MUST NOT）。
A router originates a PFM message when it needs to distribute information using a PFM message to other routers in the network. When a message is originated depends on what information is distributed. For instance, this document defines a TLV to distribute information about active sources. When a router has a new active source, a PFM message should be sent as soon as possible. Hence, a PFM message should be sent every time there is a new active source. However, the TLV also contains a holdtime and PFM messages need to be sent periodically. Generally speaking, a PFM message would typically be sent when there is a local state change, causing information to be distributed with the PFM to change. Also, some information may need to be sent periodically. These messages are called "triggered" and
ルータは、PFMメッセージを使用してネットワーク内の他のルータに情報を配信する必要がある場合に、PFMメッセージを発信します。メッセージの発信時期は、配信される情報によって異なります。たとえば、このドキュメントでは、アクティブなソースに関する情報を配布するTLVを定義しています。ルータに新しいアクティブソースがある場合、PFMメッセージをできるだけ早く送信する必要があります。したがって、新しいアクティブなソースがあるたびにPFMメッセージを送信する必要があります。ただし、TLVには保持時間も含まれており、PFMメッセージを定期的に送信する必要があります。一般的に言えば、PFMメッセージは通常、ローカルの状態が変化したときに送信され、PFMで情報が配信されるようになります。また、一部の情報は定期的に送信する必要がある場合があります。これらのメッセージは「トリガー」と呼ばれ、
"periodic" messages, respectively. Each TLV definition will need to define when a triggered PFM message needs to be originated, whether or not to send periodic messages, and how frequently to send them.
それぞれ「定期的な」メッセージ。各TLV定義は、トリガーされたPFMメッセージをいつ発信する必要があるか、定期的なメッセージを送信するかどうか、およびメッセージを送信する頻度を定義する必要があります。
A router MUST NOT originate more than Max_PFM_Message_Rate messages per minute. This document does not mandate how this should be implemented; some possible ways could be having a minimal time between each message, counting the number of messages originated and resetting the count every minute, or using a leaky bucket algorithm. One benefit of using a leaky bucket algorithm is that it can handle bursts better. The default value of Max_PFM_Message_Rate is 6. The value MUST be configurable. Depending on the network, one may want to use a larger value of Max_PFM_Message_Rate to favor propagation of new information, but with a large number of routers and many updates, the total number of messages might become too large and require too much processing.
ルーターは、毎分Max_PFM_Message_Rateメッセージを発信してはなりません（MUST NOT）。このドキュメントでは、これをどのように実装するかを規定していません。考えられるいくつかの方法は、各メッセージ間の時間を最小限にする、発信されたメッセージの数をカウントして毎分カウントをリセットする、またはリーキーバケットアルゴリズムを使用することです。リーキーバケットアルゴリズムを使用する利点の1つは、バーストをより適切に処理できることです。 Max_PFM_Message_Rateのデフォルト値は6です。値は構成可能でなければなりません。ネットワークによっては、Max_PFM_Message_Rateの値を大きくして新しい情報の伝達を優先することもできますが、ルーターの数と更新の数が多いと、メッセージの総数が大きくなりすぎて、処理が過剰になる場合があります。
There MUST be a minimum of Min_PFM_Message_Gap milliseconds between each originated message. The default value of Min_PFM_Message_Gap is 1000 (1 second). The value MUST be configurable.
各発信メッセージの間には、最小Min_PFM_Message_Gapミリ秒が必要です。 Min_PFM_Message_Gapのデフォルト値は1000（1秒）です。値は構成可能でなければなりません。
Unless otherwise specified by the TLV definitions, there is no relationship between different TLVs, and an implementation can choose whether to combine TLVs in one message or across separate messages. It is RECOMMENDED to combine multiple TLVs in one message to reduce the number of messages, but it is also RECOMMENDED that the message be small enough to avoid fragmentation at the IP layer. When a triggered PFM message needs to be sent due to a state change, a router MAY send a message containing only the information that changed. If there are many changes occurring at about the same time, it might be possible to combine multiple changes in one message. In the case where periodic messages are also needed, an implementation MAY include periodic PFM information in a triggered PFM. For example, if some information needs to be sent every 60 seconds and a triggered PFM message is about to be sent 20 seconds before the next periodic PFM message was scheduled, the triggered PFM message might include the periodic information and the next periodic PFM message can then be scheduled 60 seconds after that rather than 20 seconds later.
TLV定義で特に指定されていない限り、異なるTLVの間に関係はなく、実装では、TLVを1つのメッセージに結合するか、別々のメッセージに結合するかを選択できます。 1つのメッセージに複数のTLVを組み合わせてメッセージの数を減らすことをお勧めしますが、メッセージがIP層での断片化を避けるのに十分なほど小さいこともお勧めします。状態の変化のためにトリガーされたPFMメッセージを送信する必要がある場合、ルーターは変更された情報のみを含むメッセージを送信してもよい（MAY）。ほぼ同時に多くの変更が発生している場合は、1つのメッセージに複数の変更を組み合わせることができる場合があります。定期的なメッセージも必要な場合、実装は、トリガーされたPFMに定期的なPFM情報を含めることができます。たとえば、一部の情報を60秒ごとに送信する必要があり、トリガーされたPFMメッセージが次の定期的なPFMメッセージがスケジュールされる20秒前に送信される場合、トリガーされたPFMメッセージには定期的な情報が含まれ、次の定期的なPFMメッセージはその後、20秒後ではなく、60秒後にスケジュールされます。
When a router originates a PFM message, it puts one of its own addresses in the originator field. An implementation MUST allow an administrator to configure which address is used. For a message to be received by all routers in a domain, all the routers need to have a route for this address due to the RPF-based forwarding. Hence, an administrator needs to be careful about which address to choose. When this is not configured, an implementation MUST NOT use a link- local address. It is RECOMMENDED to use an address of a virtual interface such that the originator can remain unchanged and routable independent of which physical interfaces or links may go down.
ルーターがPFMメッセージを発信すると、独自のアドレスの1つを発信元フィールドに入れます。実装では、管理者が使用するアドレスを構成できるようにする必要があります。ドメイン内のすべてのルーターがメッセージを受信するには、RPFベースの転送のため、すべてのルーターにこのアドレスへのルートが必要です。したがって、管理者はどのアドレスを選択するかについて注意する必要があります。これが構成されていない場合、実装はリンクローカルアドレスを使用してはなりません（MUST NOT）。仮想インターフェイスのアドレスを使用することをお勧めします。これにより、発信元が変更されず、ルーティングできる物理インターフェイスまたはリンクがダウンする可能性があるかどうかに関係なくルーティングできます。
The No-Forward bit MUST NOT be set, except for the case when a router receives a PIM Hello from a new neighbor or a PIM Hello with a new Generation Identifier (GenID), defined in [RFC7761], is received from an existing neighbor. In that case, an implementation MAY send PFM messages containing relevant information so that the neighbor can quickly get the correct state. The definition of the different PFM message TLVs needs to specify what, if anything, needs to be sent in this case. If such a PFM message is sent, the No-Forward bit MUST be set, and the message must be sent within 60 seconds after the neighbor state change. The processing rules for PFM messages will ensure that any other neighbors on the same link ignore the message. This behavior (and the choice of 60 seconds) is similar to what is defined for the No-Forward bit in [RFC5059].
ルーターが新しいネイバーからPIM Helloを受信した場合、または[RFC7761]で定義された新しい世代識別子（GenID）のPIM Helloを既存のネイバーから受信した場合を除いて、転送不可ビットを設定してはなりません（MUST NOT）。 。その場合、実装は関連情報を含むPFMメッセージを送信して、ネイバーがすぐに正しい状態を取得できるようにする場合があります。異なるPFMメッセージTLVの定義では、この場合、何を送信する必要があるかを指定する必要があります。このようなPFMメッセージが送信される場合は、転送不可ビットを設定する必要があり、メッセージは、ネイバーの状態が変化してから60秒以内に送信する必要があります。 PFMメッセージの処理ルールは、同じリンク上の他のネイバーがメッセージを無視することを保証します。この動作（および60秒の選択）は、[RFC5059]の転送禁止ビットに定義されている動作と似ています。
A router that receives a PFM message MUST perform the initial checks specified here. If the checks fail, the message MUST be dropped. An error MAY be logged; otherwise, the message MUST be dropped silently. If the checks pass, the contents are processed according to the processing rules of the included TLVs.
PFMメッセージを受信するルーターは、ここで指定された初期チェックを実行する必要があります。チェックが失敗した場合は、メッセージをドロップする必要があります。エラーが記録される場合があります。それ以外の場合、メッセージはサイレントにドロップする必要があります。チェックに合格した場合、コンテンツは含まれているTLVの処理ルールに従って処理されます。
In order to do further processing, a message MUST meet the following requirements. The message MUST be from a directly connected PIM neighbor and the destination address MUST be ALL-PIM-ROUTERS. Also, the interface MUST NOT be an incoming, nor a bidirectional, administrative boundary for PFM messages, see Section 3.2. If the No-Forward bit is not set, the message MUST be from the RPF neighbor of the originator address. If the No-Forward bit is set, this system, the router doing these checks, MUST have enabled the PIM protocol within the last 60 seconds. See Section 3.3 for details. In pseudocode, the algorithm is as follows:
さらに処理を行うために、メッセージは次の要件を満たさなければなりません。メッセージは直接接続されたPIMネイバーからのものでなければならず、宛先アドレスはALL-PIM-ROUTERSでなければなりません。また、インターフェースは、PFMメッセージの着信または双方向の管理境界であってはなりません（セクション3.2を参照）。 No-Forwardビットが設定されていない場合、メッセージは発信者アドレスのRPFネイバーからのものでなければなりません。 No-Forwardビットが設定されている場合、このシステム、これらのチェックを行うルーターは、最後の60秒以内にPIMプロトコルを有効にしている必要があります。詳細については、セクション3.3を参照してください。疑似コードでは、アルゴリズムは次のとおりです。
if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(PFM.src_ip_address is not a PIM neighbor) OR
(PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFM)) {
drop the message silently, optionally log error.
}
if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error.
}
} else if (more than 60 seconds elapsed since PIM enabled)) {
drop the message silently, optionally log error.
}
Note that "src_ip_address" is the source address in the IP header of the PFM message. "Originator" is the originator field inside the PFM message and is the router that originated the message. When the message is forwarded hop-by-hop, the originator address never changes, while the source address will be an address belonging to the router that last forwarded the message.
「src_ip_address」は、PFMメッセージのIPヘッダーの送信元アドレスであることに注意してください。 「発信元」は、PFMメッセージ内の発信元フィールドであり、メッセージを発信したルーターです。メッセージがホップバイホップで転送される場合、発信元アドレスは変更されませんが、送信元アドレスは、メッセージを最後に転送したルーターに属するアドレスになります。
When the message is received, the initial checks above must be performed. If it passes the checks, then for each included TLV, perform processing according to the specification for that TLV.
メッセージを受信したら、上記の初期チェックを実行する必要があります。チェックに合格した場合は、含まれている各TLVについて、そのTLVの仕様に従って処理を実行します。
After processing, the message is forwarded. Some TLVs may be omitted or modified in the forwarded message. This depends on administrative boundaries (see Section 3.2), the type specification, and the setting of the Transitive bit for the TLV. If a router supports the type, then the TLV is forwarded with no changes unless otherwise specified by the type specification. A router not supporting the given type MUST include the TLV in the forwarded message if and only if the Transitive bit is set. Whether or not a router supports the type, the value of the Transitive bit MUST be preserved if the TLV is included in the forwarded message. The message is forwarded out of all interfaces with PIM neighbors (including the interface it was received on). As specified in Section 3.2, if an interface is an outgoing boundary for any TLVs, the message MUST NOT be sent out on the interface if it is an outgoing boundary for all the TLVs in the message. Otherwise, the router MUST remove any outgoing boundary TLVs of the interface from the message and send the message out that interface with the remaining TLVs.
処理後、メッセージが転送されます。一部のTLVは、転送されたメッセージで省略または変更される場合があります。これは、管理境界（セクション3.2を参照）、タイプ仕様、およびTLVのTransitiveビットの設定によって異なります。ルータがタイプをサポートしている場合、タイプの仕様で特に指定されていない限り、TLVは変更されずに転送されます。指定されたタイプをサポートしないルーターは、Transitiveビットが設定されている場合にのみ、転送されるメッセージにTLVを含める必要があります。ルーターがタイプをサポートしているかどうかにかかわらず、TLVが転送メッセージに含まれている場合、Transitiveビットの値を保持する必要があります。メッセージは、PIMネイバーとのすべてのインターフェイスから転送されます（受信されたインターフェイスを含む）。セクション3.2で指定されているように、インターフェイスがTLVの発信境界である場合、メッセージ内のすべてのTLVの発信境界である場合、メッセージはインターフェイス上で送信してはなりません（MUST NOT）。それ以外の場合、ルーターはメッセージのインターフェイスのすべての送信境界TLVを削除し、残りのTLVを使用してそのインターフェイスからメッセージを送信する必要があります。
The generic PFM defined in the previous section can be used for distributing SG mappings about active multicast sources throughout a PIM domain. A Group Source Holdtime (GSH) TLV is defined for this purpose.
前のセクションで定義された一般的なPFMは、アクティブなマルチキャストソースに関するSGマッピングをPIMドメイン全体に配布するために使用できます。この目的のために、グループソースホールドタイム（GSH）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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1: The Transitive bit is set to 1. This means that this type will be forwarded even if a router does not support it. See Section 3.4.2.
1：Transitiveビットは1に設定されます。これは、ルーターがサポートしていない場合でも、このタイプが転送されることを意味します。セクション3.4.2を参照してください。
Type: This TLV has type 1.
タイプ：このTLVのタイプは1です。
Length: The length of the value in octets.
長さ：オクテット単位の値の長さ。
Group Address: The group that sources are to be announced for. The format for this address is given in the Encoded-Group format in [RFC7761].
グループアドレス：ソースがアナウンスされるグループ。このアドレスのフォーマットは、[RFC7761]のEncoded-Groupフォーマットで与えられます。
Src Count: The number of source addresses that are included.
Src Count：含まれる送信元アドレスの数。
Src Holdtime: The holdtime (in seconds) for the included source(s).
Src Holdtime：含まれるソースの保持時間（秒単位）。
Src Address: The source address for the corresponding group. The format for these addresses is given in the Encoded-Unicast address in [RFC7761].
送信元アドレス：対応するグループの送信元アドレス。これらのアドレスのフォーマットは、[RFC7761]のエンコードされたユニキャストアドレスで与えられます。
A PFM message MAY contain one or more Group Source Holdtime (GSH) TLVs. This is used to flood information about active multicast sources. Each FHR that is directly connected to an active multicast source originates PFM messages containing GSH TLVs. How a multicast router discovers the source of the multicast packet, and when it considers itself the FHR, follows the same procedures as the registering process described in [RFC7761]. When an FHR has decided that a register needs to be sent per [RFC7761], the SG is not registered via the PIM-SM register procedures, but the SG mapping is included in a GSH TLV in a PFM message. Note that only the SG mapping is distributed in the message: not the entire packet as would have been done with a PIM register.
PFMメッセージには、1つ以上のグループソースホールドタイム（GSH）TLVが含まれる場合があります。これは、アクティブなマルチキャストソースに関する情報をフラッディングするために使用されます。アクティブなマルチキャストソースに直接接続されている各FHRは、GSH TLVを含むPFMメッセージを発信します。マルチキャストルーターがマルチキャストパケットのソースを発見する方法、およびそれ自体がFHRであると考える場合、[RFC7761]で説明されている登録プロセスと同じ手順に従います。 FHRが[RFC7761]に従ってレジスタを送信する必要があると判断した場合、SGはPIM-SM登録手順で登録されませんが、SGマッピングはPFMメッセージのGSH TLVに含まれます。メッセージではSGマッピングのみが配布されることに注意してください。PIMレジスタで行われるようなパケット全体ではありません。
The PFM messages containing the GSH TLV are sent periodically for as long as the multicast source is active, similar to how PIM registers are sent periodically. This means that as long as the source is active, it is included in a PFM message originated every Group_Source_Holdtime_Period seconds, within the general PFM timing requirements in Section 3.3. The default value of Group_Source_Holdtime_Period is 60. The value MUST be configurable. The holdtime for the source MUST be set to either zero or Group_Source_Holdtime_Holdtime. The value of the Group_Source_Holdtime_Holdtime parameter MUST be larger than Group_Source_Holdtime_Period. It is RECOMMENDED to be 3.5 times the Group_Source_Holdtime_Period. The default value is 210 (seconds). The value MUST be configurable. A source MAY be announced with a holdtime of zero to indicate that the source is no longer active.
GIM TLVを含むPFMメッセージは、PIMレジスタが定期的に送信されるのと同様に、マルチキャストソースがアクティブである限り定期的に送信されます。これは、ソースがアクティブである限り、セクション3.3の一般的なPFMタイミング要件内で、Group_Source_Holdtime_Period秒ごとに発信されるPFMメッセージに含まれていることを意味します。 Group_Source_Holdtime_Periodのデフォルト値は60です。この値は構成可能でなければなりません。ソースの保持時間は、ゼロまたはGroup_Source_Holdtime_Holdtimeに設定する必要があります。 Group_Source_Holdtime_Holdtimeパラメータの値は、Group_Source_Holdtime_Periodよりも大きくなければなりません。 Group_Source_Holdtime_Periodの3.5倍にすることをお勧めします。デフォルト値は210（秒）です。値は構成可能でなければなりません。ソースが非アクティブであることを示すために、ソースがホールドタイム0でアナウンスされる場合があります。
If an implementation supports originating GSH TLVs with different holdtimes for different sources, it can (if needed) send multiple TLVs with the same group address. Due to the format, all the sources in the same TLV have the same holdtime.
実装が、異なる送信元に対して異なるホールドタイムを持つ発信GSH TLVをサポートする場合、（必要な場合）同じグループアドレスを持つ複数のTLVを送信できます。この形式のため、同じTLV内のすべてのソースは同じホールドタイムを持っています。
When a new source is detected, an implementation MAY send a PFM message containing just that particular source. However, it MAY also include information about other sources that were just detected, sources that are scheduled for periodic announcement later, or other types of information. See Section 3.3 for details. Note that when a new source is detected, one should trigger the sending of a PFM message as soon as possible; whereas if a source becomes inactive, there is no reason to trigger a message. There is no urgency in removing state for inactive sources. Note that the message timing requirements in Section 3.3 apply. This means that one cannot always send a triggered message immediately when a new source is detected. In order to meet the timing requirements, the sending of the message may have to be delayed for a small amount of time.
新しいソースが検出されると、実装はその特定のソースのみを含むPFMメッセージを送信できます。ただし、検出されたばかりのその他の情報源、後で定期的に発表される予定の情報源、またはその他の種類の情報も含まれる場合があります。詳細については、セクション3.3を参照してください。新しいソースが検出された場合、できるだけ早くPFMメッセージの送信をトリガーする必要があることに注意してください。一方、ソースが非アクティブになった場合、メッセージをトリガーする理由はありません。非アクティブなソースの状態を削除する緊急性はありません。セクション3.3のメッセージタイミング要件が適用されることに注意してください。つまり、新しいソースが検出されたときに、トリガーされたメッセージをすぐに送信できるとは限りません。タイミング要件を満たすために、メッセージの送信を少しの間遅らせる必要がある場合があります。
When a new PIM neighbor is detected or an existing neighbor changes GenID, an implementation MAY send a triggered PFM message containing GSH TLVs for any SG mappings it has learned by receiving PFM GSH TLVs as well as any active directly connected sources. See Section 3.3 for further details.
新しいPIMネイバーが検出された場合、または既存のネイバーがGenIDを変更した場合、実装は、PFM GSH TLVとアクティブな直接接続されたソースを受信することで学習したSGマッピングのGSH TLVを含むトリガーされたPFMメッセージを送信できます（MAY）。詳細については、セクション3.3を参照してください。
A router that receives a PFM message containing GSH TLVs MUST parse the GSH TLVs and store each of them as SG mappings with an Expiry Timer started with the advertised holdtime, that is, unless the implementation specifically does not support GSH TLVs, the router is configured to ignore GSH TLVs in general, or it is configured to ignore GSH TLVs for certain sources or groups. In particular, an administrator might configure a router not to process GSH TLVs if the router is known never to have any directly connected receivers.
GSH TLVを含むPFMメッセージを受信するルーターは、GSH TLVを解析し、アドバタイズされたホールドタイムで開始される有効期限タイマー付きのSGマッピングとしてそれぞれを保存する必要があります。つまり、実装が特にGSH TLVをサポートしていない場合は、ルーターが構成されています一般にGSH TLVを無視するか、特定のソースまたはグループのGSH TLVを無視するように構成されています。特に、管理者は、ルーターに直接接続されたレシーバーがないことがわかっている場合、GSH TLVを処理しないようにルーターを構成することがあります。
For each group that has directly connected receivers, this router SHOULD send PIM (S,G) joins for all the SG mappings advertised in the message for the group. Generally, joins are sent, but there could be, for instance, an administrative policy limiting which sources and groups to join. The SG mappings are kept alive for as long as the Expiry Timer for the source is running. Once the Expiry Timer expires, a PIM router MAY send a PIM (S,G) prune to remove itself from the tree. However, when this happens, there should be no more packets sent by the source, so it may be desirable to allow the state to time out rather than sending a prune.
受信機が直接接続されているグループごとに、このルーターは、グループのメッセージでアドバタイズされたすべてのSGマッピングのPIM（S、G）結合を送信する必要があります（SHOULD）。通常、参加は送信されますが、たとえば、参加するソースとグループを制限する管理ポリシーが存在する場合があります。 SGマッピングは、ソースの有効期限タイマーが実行されている限り存続します。 Expiry Timerが期限切れになると、PIMルーターはPIM（S、G）プルーンを送信して、ツリーから自身を削除する場合があります。ただし、これが発生すると、送信元から送信されるパケットがなくなるため、プルーンを送信するのではなく、状態をタイムアウトさせることが望ましい場合があります。
Note that a holdtime of zero has a special meaning. It is to be treated as if the source just expired, and then the state should be removed. Source information MUST NOT be removed due to the source being omitted in a message. For instance, if there are a large number of sources for a group, there may be multiple PFM messages, each message containing a different list of sources for the group.
ゼロの保持時間には特別な意味があることに注意してください。ソースが期限切れになったように扱われ、状態は削除されます。メッセージでソースが省略されているため、ソース情報を削除してはなりません（MUST NOT）。たとえば、グループに多数のソースがある場合、複数のPFMメッセージがあり、各メッセージにはグループのソースの異なるリストが含まれています。
The PIM register procedure is designed to deliver multicast packets to the RP in the absence of an SPT from the RP to the source. The register packets received on the RP are decapsulated and forwarded down the shared tree to the LHRs. As soon as an SPT is built, multicast packets would flow natively over the SPT to the RP or LHR and the register process would stop. The PIM register process ensures packet delivery until an SPT is in place reaching the FHR. If the packets were not unicast encapsulated to the RP, they would be dropped by the FHR until the SPT is set up. This functionality is important for applications where the initial packet(s) must be received for the application to work correctly. Another reason would be for bursty sources. If the application sends out a multicast packet every 4 minutes (or longer), the SPT is torn down (typically after 3:30 minutes of inactivity) before the next packet is forwarded down the tree. This will prevent multicast packets from ever being forwarded. A well-behaved application should be able to deal with packet loss since IP is a best-effort-based packet delivery system. But in reality, this is not always the case.
PIM登録手順は、RPから送信元へのSPTがない場合に、マルチキャストパケットをRPに配信するように設計されています。 RPで受信されたレジスタパケットはカプセル化が解除され、共有ツリーを下ってLHRに転送されます。 SPTが構築されるとすぐに、マルチキャストパケットはSPTを介してネイティブでRPまたはLHRに流れ、登録プロセスが停止します。 PIM登録プロセスは、SPTが配置されてFHRに到達するまで、パケット配信を保証します。パケットがRPにユニキャストカプセル化されていなかった場合、SPTがセットアップされるまでFHRによってドロップされます。この機能は、アプリケーションが正しく機能するために最初のパケットを受信する必要があるアプリケーションにとって重要です。もう1つの理由は、バースト性のあるソースのためです。アプリケーションが4分（またはそれ以上）ごとにマルチキャストパケットを送信する場合、次のパケットがツリーの下に転送される前に、SPTが破棄されます（通常、非アクティブの3:30分後）。これにより、マルチキャストパケットが転送されなくなります。 IPはベストエフォートベースのパケット配信システムであるため、適切に動作するアプリケーションはパケット損失に対処できるはずです。しかし、実際には、これが常に当てはまるわけではありません。
With the procedures defined in this document, the packet(s) received by the FHR will be dropped until the LHR has learned about the source and the SPT is built. For bursty sources or applications sensitive for the delivery of the first packet, that means this solution would not be very applicable. This solution is mostly useful for applications that don't have a strong dependency on the initial packet(s) and have a fairly constant data rate, like video distribution, for example. For applications with strong dependency on the initial packet(s), using BIDIR-PIM [RFC5015] or SSM [RFC4607] is recommended. The protocol operations are much simpler compared to PIM-SM; they will cause less churn in the network. Both guarantee best-effort delivery for the initial packet(s).
このドキュメントで定義されている手順では、LHRがソースについて学習し、SPTが構築されるまで、FHRが受信したパケットはドロップされます。最初のパケットの配信に敏感なバースト性のあるソースまたはアプリケーションの場合、このソリューションはあまり適用できません。このソリューションは、最初のパケットに強く依存しておらず、ビデオ配信など、データレートがかなり一定のアプリケーションに最も役立ちます。最初のパケットに強く依存するアプリケーションでは、BIDIR-PIM [RFC5015]またはSSM [RFC4607]の使用をお勧めします。プロトコル操作はPIM-SMに比べてはるかに簡単です。それらはネットワークのチャーンを少なくします。どちらも最初のパケットのベストエフォート配信を保証します。
In a PIM-SM deployment where the network becomes partitioned due to link or node failure, it is possible that the RP becomes unreachable to a certain part of the network. New sources that become active in that partition will not be able to register to the RP and receivers within that partition will not be able to receive the traffic. Ideally, having a candidate RP in each partition is desirable, but which routers will form a partitioned network is something unknown in advance. In order to be fully resilient, each router in the network may end up being a candidate RP. This would increase the operational complexity of the network.
リンクまたはノードの障害によりネットワークが分割されるPIM-SM配置では、RPがネットワークの特定の部分に到達できなくなる可能性があります。そのパーティションでアクティブになる新しいソースはRPに登録できなくなり、そのパーティション内の受信者はトラフィックを受信できなくなります。理想的には、各パーティションに候補RPがあることが望ましいですが、どのルーターがパーティション化されたネットワークを形成するかは、事前に不明です。完全に回復力を持たせるために、ネットワーク内の各ルーターが最終的に候補RPになる場合があります。これにより、ネットワークの運用が複雑になります。
The solution described in this document does not suffer from that problem. If a network becomes partitioned and new sources become active, the receivers in that partition will receive the SG mappings and join the source tree. Each partition works independently of the other partitions and will continue to have access to sources within that partition. Once the network has healed, the periodic flooding of SG mappings ensures that they are reflooded into the other partitions and then other receivers can join the newly learned sources.
このドキュメントで説明されているソリューションは、その問題の影響を受けません。ネットワークが分割され、新しいソースがアクティブになると、そのパーティションのレシーバーはSGマッピングを受信し、ソースツリーに参加します。各パーティションは他のパーティションとは独立して機能し、そのパーティション内のソースに引き続きアクセスできます。ネットワークが修復されると、SGマッピングの定期的なフラッディングにより、SGマッピングが他のパーティションに再度フラッディングされ、他の受信者が新しく学習したソースに参加できるようになります。
This document contains a number of configurable parameters. These parameters are formally defined in Sections 3.3 and 4.2, but they are repeated here for ease of reference. These parameters all have default values as noted below.
このドキュメントには、設定可能なパラメータがいくつか含まれています。これらのパラメータはセクション3.3と4.2で正式に定義されていますが、参照しやすいようにここで繰り返します。これらのパラメータには、以下に示すようにすべてデフォルト値があります。
Max_PFM_Message_Rate: The maximum number of PFM messages a router is allowed to originate per minute; see Section 3.3 for details. The default value is 6.
Max_PFM_Message_Rate：ルーターが1分間に発信できるPFMメッセージの最大数。詳細はセクション3.3を参照してください。デフォルト値は6です。
Min_PFM_Message_Gap: The minimum amount of time between each PFM message originated by a router in milliseconds; see Section 3.3 for details. The default is 1000.
Min_PFM_Message_Gap：ルーターが発信した各PFMメッセージ間の最小時間（ミリ秒）。詳細はセクション3.3を参照してください。デフォルトは1000です。
Group_Source_Holdtime_Period: The announcement period for Group Source Holdtime TLVs in seconds; see Section 4.2 for details. The default value is 60.
Group_Source_Holdtime_Period：秒単位のグループソースホールドタイムTLVのアナウンス期間。詳細については、セクション4.2を参照してください。デフォルト値は60です。
Group_Source_Holdtime_Holdtime: The holdtime for Group Source Holdtime TLVs in seconds; see Section 4.2 for details. The default value is 210.
Group_Source_Holdtime_Holdtime：グループソースホールドタイムTLVのホールドタイム（秒単位）。詳細については、セクション4.2を参照してください。デフォルト値は210です。
For general PIM message security, see [RFC7761]. PFM messages MUST only be accepted from a PIM neighbor, but as discussed in [RFC7761], any router can become a PIM neighbor by sending a Hello message. To control from where to accept PFM packets, one can limit on which interfaces PIM is enabled. Also, one can configure interfaces as administrative boundaries for PFM messages, see Section 3.2. The implications of forged PFM messages depend on which TLVs they contain. Documents defining new TLVs will need to discuss the security considerations for the specific TLVs. In general though, the PFM messages are flooded within the network; by forging a large number of PFM messages, one might stress all the routers in the network.
一般的なPIMメッセージセキュリティについては、[RFC7761]を参照してください。 PFMメッセージはPIMネイバーからのみ受け入れられる必要がありますが、[RFC7761]で説明されているように、Helloメッセージを送信することにより、どのルーターもPIMネイバーになることができます。 PFMパケットを受け入れる場所を制御するには、PIMを有効にするインターフェイスを制限します。また、PFMメッセージの管理境界としてインターフェースを構成することもできます。セクション3.2を参照してください。偽造されたPFMメッセージの影響は、メッセージに含まれるTLVによって異なります。新しいTLVを定義するドキュメントでは、特定のTLVのセキュリティに関する考慮事項について説明する必要があります。ただし、一般的に、PFMメッセージはネットワーク内でフラッディングされます。多数のPFMメッセージを偽造することにより、ネットワーク内のすべてのルーターに負荷をかける可能性があります。
If an attacker can forge PFM messages, then such messages may contain arbitrary GSH TLVs. An issue here is that an attacker might send such TLVs for a huge amount of sources, potentially causing every router in the network to store huge amounts of source state. Also, if there is receiver interest for the groups specified in the GSH TLVs, routers with directly connected receivers will build SPTs for the announced sources, even if the sources are not actually active. Building such trees will consume additional resources on routers that the trees pass through.
攻撃者がPFMメッセージを偽造できる場合、そのようなメッセージには任意のGSH TLVが含まれる可能性があります。ここでの問題は、攻撃者がそのようなTLVを大量のソースに送信する可能性があり、ネットワーク内のすべてのルーターが大量のソース状態を格納する可能性があることです。また、GSH TLVで指定されたグループにレシーバーの関心がある場合、直接接続されたレシーバーを持つルーターは、ソースが実際にアクティブでなくても、アナウンスされたソースのSPTを構築します。そのようなツリーを構築すると、ツリーが通過するルーター上の追加のリソースが消費されます。
PIM-SM link-local messages can be authenticated using IPsec, see Section 6.3 of [RFC7761] and [RFC5796]. Since PFM messages are link-local messages sent hop-by-hop, a link-local PFM message can be authenticated using IPsec such that a router can verify that a message was sent by a trusted neighbor and has not been modified. However, to verify that a received message contains correct information announced by the originator specified in the message, one will have to trust every router on the path from the originator and that each router has authenticated the received message.
PIM-SMリンクローカルメッセージはIPsecを使用して認証できます。[RFC7761]のセクション6.3と[RFC5796]をご覧ください。 PFMメッセージはホップバイホップで送信されるリンクローカルメッセージであるため、IP-secを使用してリンクローカルPFMメッセージを認証できるため、ルーターはメッセージが信頼できるネイバーから送信され、変更されていないことを確認できます。ただし、受信したメッセージにメッセージで指定された発信者がアナウンスした正しい情報が含まれていることを確認するには、発信者からのパス上のすべてのルーターを信頼し、各ルーターが受信したメッセージを認証している必要があります。
This document registers a new PIM message type for the PIM Flooding Mechanism (PFM) with the name "PIM Flooding Mechanism" in the "PIM Message Types" registry with the value of 12.
このドキュメントでは、「PIMメッセージタイプ」レジストリに「PIMフラッディングメカニズム」という名前のPIMフラッディングメカニズム（PFM）の新しいPIMメッセージタイプを値12で登録します。
IANA has also created a registry for PFM TLVs called "PIM Flooding Mechanism Message Types". Assignments for the registry are to be made according to the policy "IETF Review" as defined in [RFC8126]. The initial content of the registry is as follows:
IANAは、「PIMフラッディングメカニズムメッセージタイプ」と呼ばれるPFM TLVのレジストリも作成しました。レジストリの割り当ては、[RFC8126]で定義されているポリシー「IETFレビュー」に従って行われます。レジストリの初期内容は次のとおりです。
Type Name Reference
---------------------------------------------
0 Reserved [RFC8364]
1 Source Group Holdtime [RFC8364]
2-32767 Unassigned
[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>。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <https://www.rfc-editor.org/info/rfc5059>.
[RFC5059] Bhaskar、N.、Gall、A.、Lingard、J.、S。Venaas、「Bootstrap Router（BSR）Mechanism for Protocol Independent Multicast（PIM）」、RFC 5059、DOI 10.17487 / RFC5059、January 2008、 <https://www.rfc-editor.org/info/rfc5059>。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.
[RFC5796] Atwood、W.、Islam、S。、およびM. Siami、「Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode（PIM-SM）Link-Local Messages」、RFC 5796、DOI 10.17487 / RFC5796、March 2010、 <https://www.rfc-editor.org/info/rfc5796>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「Protocol Independent Multicast-Dense Mode（PIM-DM）：Protocol Specification（Revised）」、RFC 3973、DOI 10.17487 / RFC3973、2005年1月、< https://www.rfc-editor.org/info/rfc3973>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H。およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<https://www.rfc-editor.org/info/rfc4607>。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <https://www.rfc-editor.org/info/rfc5015>.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<https：/ /www.rfc-editor.org/info/rfc5015>。
Acknowledgments
謝辞
The authors would like to thank Arjen Boers for contributing to the initial idea, and David Black, Stewart Bryant, Yiqun Cai, Papadimitriou Dimitri, Toerless Eckert, Dino Farinacci, Alvaro Retana, and Liang Xia for their very helpful comments on the document.
著者は、最初のアイデアに貢献してくれたArjen Boersに感謝し、David Black、Stewart Bryant、Yiqun Cai、Papadimitriou Dimitri、Toerless Eckert、Dino Farinacci、Alvaro Retana、Liang Xiaは、このドキュメントに対する非常に役立つコメントに感謝します。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands Cisco Systems、Inc. Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose CA 95134 United States of America
Stig Venaas Cisco Systems、Inc. Tasman Drive San Jose CA 95134アメリカ合衆国
Email: stig@cisco.com
Michael Brig Aegis BMD Program Office 17211 Avenue D, Suite 160 Dahlgren VA 22448-5148 United States of America
Michael Brig Aegis BMD Program Office 17211 Avenue D、Suite 160 Dahlgren VA 22448-5148アメリカ合衆国
Email: michael.brig@mda.mil
Anders Jonasson Swedish Defence Material Administration (FMV) Loennvaegen 4 Vaexjoe 35243 Sweden
Anders Jonasson Swedish Defense Material Administration（FMV）Loennvaegen 4 Vaexjoe 35243スウェーデン
Email: anders@jomac.se