[要約] RFC 9466 は、PIM Assert メッセージのパッキングを定義し、複数の IP マルチキャストフローに関する情報を単一の PackedAssert メッセージで送受信することで、LAN 上の PIM パケット数を削減し、単一のフォワーダーの選出を迅速化し、重複 IP マルチキャストパケットの数を減らすことを目的としています。
Internet Engineering Task Force (IETF) Y. Liu, Ed.
Request for Comments: 9466 China Mobile
Category: Standards Track T. Eckert, Ed.
ISSN: 2070-1721 M. McBride
Futurewei
Z. Zhang
ZTE Corporation
October 2023
When PIM Sparse Mode (PIM-SM), including PIM Source-Specific Multicast (PIM-SSM), is used in shared LAN networks, there is often more than one upstream router. This can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers.
PIMソース固有のマルチキャスト（PIM-SSM）を含むPIMスパースモード（PIM-SM）が共有LANネットワークで使用される場合、多くの場合、複数のアップストリームルーターがあります。これにより、これらのPIMルーターによって転送されるIPマルチキャストパケットの重複につながる可能性があります。PIMアサートメッセージは、これらのルーター間のIPマルチキャストトラフィックフローごとに単一のフォワーダーを選択するために使用されます。
This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred.
このドキュメントは、単一のPackedAssertメッセージで複数のIPマルチキャストフローの情報を送信および受信するメカニズムを定義します。この最適化により、LAN上のPIMパケットの総数が減少するため、単一のフォワーダーの選挙をスピードアップして、発生した重複したIPマルチキャストパケットの数を減らすことができます。
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/rfc9466.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9466で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Problem Statement
3. Specification
3.1. PIM Packed Assert Capability Hello Option
3.2. Assert Packing Message Formats
3.3. PackedAssert Mechanism
3.3.1. Sending PackedAssert Messages
3.3.1.1. Handling of Reception-Triggered Assert Records
3.3.1.2. Handling of Timer Expiry-Triggered Assert Records
3.3.1.3. Beneficial Delay in Sending PackedAssert Messages
3.3.1.4. Handling Assert/PackedAssert Message Loss
3.3.1.5. Optimal Degree of Assert Record Packing
3.3.2. Receiving PackedAssert Messages
4. Packet Formats
4.1. PIM Packed Assert Capability Hello Option
4.2. Assert Message Format
4.3. Simple PackedAssert Message Format
4.4. Aggregated PackedAssert Message Format
4.4.1. Source Aggregated Assert Record
4.4.2. RP Aggregated Assert Record
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Use Case Examples
A.1. Enterprise Network
A.2. Video Surveillance
A.3. Financial Services
A.4. IPTV Broadcast Video
A.5. MVPN MDT
A.6. Special L2 Services
Acknowledgments
Authors' Addresses
When PIM-SM is used in shared LAN networks, there is typically more than one upstream router. When duplicate data packets appear on the LAN from different upstream routers, assert packets are sent from these routers to elect a single forwarder according to [RFC7761]. The PIM Assert messages are sent periodically to keep the Assert state. The PIM Assert message carries information about a single multicast source and group, along with the corresponding Metric and Metric Preference of the route towards the source or PIM Rendezvous Point (RP).
共有LANネットワークでPIM-SMを使用すると、通常、複数の上流ルーターがあります。さまざまな上流のルーターからLANに複製データパケットが表示されると、[RFC7761]に従って単一のフォワーダーを選択するために、これらのルーターからアサートパケットが送信されます。PIMアサートメッセージは、アサート状態を維持するために定期的に送信されます。PIMアサートメッセージには、ソースまたはPIMランデブーポイント（RP）へのルートの対応するメトリックおよびメトリック優先度とともに、単一のマルチキャストソースとグループに関する情報が含まれています。
This document defines a mechanism to encode the information of multiple PIM Assert messages into a single PackedAssert message. This allows sending and receiving information for multiple IP multicast flows in a single PackedAssert message without changing the PIM Assert state machinery. It reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets. This can be particularly helpful when there is traffic for a large number of multicast groups or SSM channels and PIM packet processing performance of the routers is slow.
このドキュメントでは、複数のPIMアサートメッセージの情報を単一のPackedAssertメッセージにエンコードするメカニズムを定義します。これにより、PIMアサート状態の機械を変更せずに、単一のPackedAssertメッセージで複数のIPマルチキャストフローの情報を送信および受信できます。LAN上のPIMパケットの総数を削減するため、単一のフォワーダーの選挙をスピードアップして、重複するIPマルチキャストパケットの数を減らすことができます。これは、多数のマルチキャストグループまたはSSMチャネルのトラフィックがあり、ルーターのPIMパケット処理パフォーマンスが遅い場合に特に役立ちます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader is expected to be familiar with the terminology of [RFC7761]. The following lists the abbreviations repeated in this document.
読者は[RFC7761]の用語に精通していると予想されます。次のリストには、このドキュメントで繰り返された略語がリストされています。
AT:
で：
Assert Timer
アサートタイマー
DR:
DR：
Designated Router
指定ルーター
RP:
RP：
Rendezvous Point
ランデブーポイント
RPF:
RPF：
Reverse Path Forwarding
逆パス転送
RPT:
RPT：
RP Tree
RPツリー
SPT:
SPT：
Shortest Path Tree
最短のパスツリー
PIM Asserts occur in many deployments. See Appendix A for explicit examples and explanations of why it is often not possible to avoid.
PIMアサートは多くの展開で発生します。明示的な例と説明を避けることができない理由の説明については、付録Aを参照してください。
PIM Assert state depends mainly on the network topology. As long as there is a Layer 2 (L2) network with more than two PIM routers, there may be multiple upstream routers, which can cause duplicate multicast traffic to be forwarded and assert processing to occur.
PIMアサート状態は、主にネットワークトポロジに依存します。2つ以上のPIMルーターを備えたレイヤー2（L2）ネットワークがある限り、複数の上流のルーターが存在する場合があります。これにより、複数のマルチキャストトラフィックが転送され、処理が発生する可能性があります。
As the multicast services become widely deployed, the number of multicast entries increases, and a large number of Assert messages may be sent in a very short period when multicast data packets trigger PIM assert processing in the shared LAN networks. The PIM routers need to process a large number of small PIM assert packets in a very short time. As a result, the device load is very large. The assert packet may not be processed in time or even discarded, thus extending the time of traffic duplication in the network.
マルチキャストサービスが広く展開されると、マルチキャストエントリの数が増加し、マルチキャストデータパケットが共有LANネットワークでPIMアサート処理をトリガーすると、非常に短い期間に多数のアサートメッセージが送信される場合があります。PIMルーターは、非常に短い時間で多数の小さなPIMアサートパケットを処理する必要があります。その結果、デバイスの負荷は非常に大きいです。ASSERTパケットは、時間内に処理されたり、破棄されたりすることさえないため、ネットワーク内のトラフィックの複製時間が延長されます。
The PIM Assert mechanism can only be avoided by designing the network to be without transit subnets with multiple upstream routers. For example, an L2 ring between routers can sometimes be reconfigured to be a ring of point-to-point subnets connected by the routers. However, these Layer 2 (L2) and Layer 3 (L3) topology changes are undesirable when they are only done to enable IP multicast with PIM because they increase the cost of introducing IP multicast with PIM.
PIMアサートメカニズムは、複数の上流ルーターを備えたトランジットサブネットなしでネットワークを設計することによってのみ回避できます。たとえば、ルーター間のL2リングは、ルーターで接続されたポイントツーポイントサブネットのリングになるように再構成される場合があります。ただし、これらのレイヤー2（L2）とレイヤー3（L3）トポロジの変化は、PIMでIPマルチキャストを導入するコストを増加させるため、PIMでIPマルチキャストを有効にするためにのみ行われる場合、望ましくありません。
These designs are also not feasible when specific L2 technologies are needed. For example, various L2 technologies for rings provide sub-50 msec failover mechanisms, something not possible equally with a ring composed from L3 subnets. Likewise, IEEE Time-Sensitive Networking mechanisms would require an L2 topology that cannot simply be replaced by an L3 topology. L2 sub-topologies can also significantly reduce the cost of deployment.
これらの設計は、特定のL2テクノロジーが必要な場合にも実現可能ではありません。たとえば、リング用のさまざまなL2テクノロジーは、L3サブネットから構成されるリングで等しく不可能なものではありません。同様に、IEEEの時間依存ネットワーキングメカニズムには、L3トポロジに置き換えることはできないL2トポロジが必要です。L2サブトポロジーは、展開コストを大幅に削減することもできます。
This document defines three elements in support of PIM assert packing:
このドキュメントでは、PIMアサートパッキングをサポートする3つの要素を定義します。
1. The PIM Packed Assert Capability Hello Option
1. PIMパックアサート機能Hello Option
2. The encoding of PackedAssert messages
2. PackedAssertメッセージのエンコード
3. How to send and receive PackedAssert messages
3. PackedAssertメッセージの送信と受信方法
The PIM Packed Assert Capability Hello Option (Section 4.1) is used to announce support for the assert packing mechanisms specified in this document. PackedAssert messages (Section 3.2) MUST NOT be used unless all PIM routers in the same subnet announce this option.
PIM Packed Assert機能Hello Option（セクション4.1）は、このドキュメントで指定されたアサートパッキングメカニズムのサポートを発表するために使用されます。同じサブネットのすべてのPIMルーターがこのオプションを発表しない限り、PackedAssertメッセージ（セクション3.2）は使用しないでください。
The PIM Assert message, as defined in Section 4.9.6 of [RFC7761], describes the parameters of a (*,G) or (S,G) assert using the following information elements: Rendezvous Point Tree flag (R), Source Address, Group Address, Metric, and Metric Preference. This document calls this information an "assert record".
[RFC7761]のセクション4.9.6で定義されているPIMアサートメッセージは、次の情報要素を使用してA（*、g）または（s、g）のパラメーターを説明しています。、グループアドレス、メトリック、およびメトリックの好み。このドキュメントは、この情報を「アサートレコード」と呼びます。
This document introduces two new PIM Assert message encodings through the allocation and use of two flags in the PIM Assert message header [RFC9436]: the Packed (P) and the Aggregated (A) flags.
このドキュメントでは、PIM Assert Message Header [RFC9436]の2つのフラグの割り当てと使用を通じて、2つの新しいPIMアサートメッセージエンコーディングを紹介します。
If P=0, the message is a (non-packed) PIM Assert message as specified in [RFC7761]. See Section 4.2. In this case, the A flag MUST be set to 0 and MUST be ignored on receipt.
p = 0の場合、メッセージは[rfc7761]で指定されているように、（非パック）pimアサートメッセージです。セクション4.2を参照してください。この場合、Aフラグは0に設定する必要があり、受領時に無視する必要があります。
If P=1, then the message is called a "PackedAssert message", and the type and hence encoding format of the payload are determined by the A flag.
p = 1の場合、メッセージは「packedAssertメッセージ」と呼ばれ、したがってペイロードのタイプとエンコード形式はAフラグによって決定されます。
If A=0, then the message body is a sequence of assert records. This is called a "Simple PackedAssert message". See Section 4.3.
a = 0の場合、メッセージ本文はアサートレコードのシーケンスです。これは「Simple PackedAssertメッセージ」と呼ばれます。セクション4.3を参照してください。
If A=1, then the message body is a sequence of aggregated assert records. This is called an "Aggregated PackedAssert message". See Section 4.4.
a = 1の場合、メッセージ本文は集約されたアサートレコードのシーケンスです。これは「集計されたPackedAssertメッセージ」と呼ばれます。セクション4.4を参照してください。
Two aggregated assert record types are specified.
2つの集計されたアサートレコードタイプが指定されています。
The "Source Aggregated Assert Record" (see Section 4.4.1) encodes one (common) Source Address, Metric, and Metric Preference as well as a list of one or more Group Addresses. Source Aggregated Assert Records provide a more compact encoding than the Simple PackedAssert message format when multiple (S,G) flows share the same source S. A single Source Aggregated Assert Record with n Group Addresses represents the information of assert records for (S,G1)...(S,Gn).
「ソース集約されたアサートレコード」（セクション4.4.1を参照）は、1つの（共通）ソースアドレス、メトリック、およびメトリックの好みと、1つ以上のグループアドレスのリストをエンコードします。ソース集約されたアサートレコードは、複数（s、g）フローが同じソースSを共有する場合、単純なパッケダサートメッセージ形式よりもコンパクトなエンコードを提供します。）...（s、gn）。
The "RP Aggregated Assert Record" (see Section 4.4.2) encodes one common Metric and Metric Preference as well as a list of "Group Records", each of which encodes a Group Address and a list of zero or more Source Addresses with a count. This is called an "RP Aggregated Assert Record", because with standard RPF according to [RFC7761], all the Group Addresses that use the same RP will have the same Metric and Metric Preference.
「RP集約されたアサートレコード」（セクション4.4.2を参照）は、1つの一般的なメトリックとメトリックの好みと、「グループレコード」のリストと、それぞれがグループアドレスとゼロ以上のソースアドレスのリストをエンコードします。カウント。これは「RP集約されたアサートレコード」と呼ばれます。これは、[RFC7761]に従って標準のRPFを使用すると、同じRPを使用するすべてのグループアドレスが同じメトリックとメトリックの好みを持つためです。
RP Aggregation Assert Records provide a more compact encoding than the Simple PackedAssert message format for (*,G) flows. The Source Address is optionally used in the assert procedures in [RFC7761] to indicate the source(s) that triggered the assert; otherwise, the Source Address is set to 0 in the assert record.
RPアグリゲーションアサートレコードは、（*、g）フローの単純なPackedAssertメッセージ形式よりも、よりコンパクトなエンコードを提供します。ソースアドレスは、[RFC7761]のアサート手順でオプションで使用され、アサートをトリガーしたソースを示すために使用されます。それ以外の場合、ソースアドレスはアサートレコードで0に設定されています。
Both Source Aggregated Assert Records and RP Aggregated Assert Records also include the R flag, which maintains its semantics from [RFC7761] but also distinguishes the encodings. Source Aggregated Assert Records have R=0, as (S,G) assert records do in [RFC7761]. RP Aggregated Assert Records have R=1, as (*,G) assert records do in [RFC7761].
ソース集約されたアサートレコードとRP集約されたアサートレコードの両方に、[RFC7761]からセマンティクスを維持するが、エンコーディングも区別するRフラグも含まれています。ソース集約されたアサートレコードには、[rfc7761]で（s、g）アサートレコードが行うように、r = 0があります。RP集約されたアサートレコードには、（*、g）アサートレコードが[RFC7761]で行うように、r = 1を持っています。
PackedAsserts do not change the PIM Assert state machine specification [RFC7761]. Instead, sending and receiving of PackedAssert messages, as specified in the following subsections, are logically new packetization options for assert records in addition to the (non-packed) Assert message [RFC7761]. There is no change to the assert record information elements transmitted or their semantics. They are just transmitted in fewer but larger packets, and a fewer total number of bytes is used to encode the information elements. As a result, PIM routers should be able to send and receive assert records faster and/or with less processing overhead.
PackedAssertsは、PIM Assert State Machine Specification [RFC7761]を変更しません。代わりに、以下のサブセクションで指定されているように、パックダッサートメッセージの送信と受信は、（パックされていない）アサートメッセージ[RFC7761]に加えて、論理的に新しいパケット化オプションです。送信されたアサートレコード情報要素またはそれらのセマンティクスに変更はありません。それらは、より少ないが大きなパケットで送信され、情報要素をエンコードするために使用されるバイトの総数が少なくなります。その結果、PIMルーターは、アサートレコードをより速く、またはより少ないオーバーヘッドでアサートレコードを送信および受信できるはずです。
When using assert packing, the regular Assert message encoding [RFC7761] with A=0 and P=0 is still allowed to be sent. Routers are free to choose which PackedAssert message format they send -- simple (Section 4.3) and/or aggregated (Section 4.4).
Assert Packingを使用する場合、A = 0およびP = 0で[RFC7761]をエンコードする通常のアサートメッセージを送信することが許可されています。ルーターは、送信するパッカサートメッセージ形式（シンプル（セクション4.3）および/または集約（セクション4.4）を自由に選択できます。
* When any PIM routers on the LAN have not signaled support for assert packing, implementations MUST only send Asserts and MUST NOT send PackedAsserts under any condition.
* LAN上のPIMルーターがアサートパッキングのサポートを合図していない場合、実装はアサートのみを送信する必要があり、どの条件下でパックダッサートを送信してはなりません。
* The protocol or system conditions for which an implementation sends PackedAsserts instead of Asserts are out of scope for this specification. Protocol conditions include protocol triggers such as data-triggered asserts or Assert Timer (AT) expiry-triggered asserts, and system conditions include high or low load or control plane packet reception rates.
* 実装がアサートの代わりにPackedAssertsを送信するプロトコルまたはシステム条件は、この仕様の範囲外です。プロトコル条件には、データトリガーされたアサートまたはアサートタイマー（AT）有効期限トリガーアサートなどのプロトコルトリガーが含まれ、システム条件には高負荷または低負荷またはコントロールプレーンパケット受信率が含まれます。
* Implementations are expected to specify in documentation and/or management interfaces (such as a YANG data model) which PackedAssert message formats they can send and under which conditions they will send them.
* 実装は、ドキュメントおよび/または管理インターフェイス（Yangデータモデルなど）で、送信できるメッセージ形式と送信条件の下で指定することが期待されています。
* Implementations SHOULD be able to indicate to the operator (such as through a YANG data model) how many Assert and PackedAssert messages were sent/received and how many assert records were sent/ received.
* 実装は、オペレーター（ヤンデータモデルなど）にいくつのアサートおよびパックダッサートメッセージが送信/受信され、アサートレコードが送信/受信されたかを示すことができるはずです。
* A configuration option SHOULD be available to disable PackedAssert operations. PIM-SM implementations [RFC7761] that introduce support for assert packing from day one MAY omit this configuration option.
* PackedAssert操作を無効にするために、構成オプションを使用できる必要があります。初日からのアサートパッキングのサポートを導入するPIM-SM実装[RFC7761]は、この構成オプションを省略する可能性があります。
When a PIM router has an assert record ready to send according to [RFC7761], it calls one of the following functions:
PIMルーターが[RFC7761]に従って送信する準備ができているアサートレコードを持っている場合、次の機能のいずれかを呼び出します。
* send Assert(S,G) / send Assert(*,G) ([RFC7761], Section 4.2)
* assert（s、g） / send assert（*、g）（[rfc7761]、セクション4.2）を送信
* send Assert(S,G) / send AssertCancel(S,G) ([RFC7761], Section 4.6.1)
* assert（s、g） / send assertcancel（s、g）（[rfc7761]、セクション4.6.1）を送信
* send Assert(*,G) / send AssertCancel(*,G) ([RFC7761], Section 4.6.2)
* assert（*、g） / send assertcancel（*、g）（[rfc7761]、セクション4.6.2）を送信
* send Assert(S,G) ([RFC7761], Section 4.8.2)
* assert（s、g）（[rfc7761]、セクション4.8.2）を送信
If sending of PackedAsserts is possible on the network, instead of sending an Assert message with an assert record, any of these calls MAY instead result in the PIM implementation remembering the assert record and continuing with further processing for other flows, which may result in additional assert records.
ネットワークでパックダッサートの送信が可能な場合、アサートレコードでアサートメッセージを送信する代わりに、これらの呼び出しのいずれかがアサートレコードを記憶し、他のフローのさらなる処理を続けるPIM実装につながる可能性があります。レコードを主張します。
PIM MUST then create PackedAssert messages from the remembered assert records and schedule them for sending according to the considerations in the following subsections.
PIMは、記憶されているアサートレコードからPackedAssertメッセージを作成し、以下のサブセクションの考慮事項に従って送信するようにスケジュールする必要があります。
Avoiding additional delay because of assert packing compared to immediately scheduling Assert messages is most critical for assert records that are triggered by reception of data or reception of asserts against which the router is in the "I am Assert Winner" state. In these cases, the router SHOULD send out an Assert or PackedAssert message containing this assert record as soon as possible to minimize the time in which duplicate IP multicast packets can occur.
アサートパッキングのために追加の遅延を回避することは、すぐにスケジューリングすることと比較して、データの受信またはルーターが「I Am Assert Winner」状態にあるアサートの受信によってトリガーされるアサートレコードにとって最も重要です。これらの場合、ルーターは、このアサートレコードを含むアサートまたはパックダッサートメッセージをできるだけ早く送信して、重複するIPマルチキャストパケットが発生する可能性がある時間を最小限に抑える必要があります。
To avoid additional delay in this case, the router should employ appropriate assert packing and scheduling mechanisms, as explained here.
この場合の追加の遅延を回避するために、ルーターはここで説明するように、適切なアサートパッキングおよびスケジューリングメカニズムを採用する必要があります。
Asserts/PackedAsserts created from reception-triggered assert records should be scheduled for serialization with a higher priority than those created because of other protocol or system conditions. They should also bypass other PIM messages that can create significant bursts, such as PIM join/prune messages.
受信トリガーされたアサートレコードから作成されたAsserts/PackedAssertsは、他のプロトコルやシステム条件のために作成されたものよりも優先度が高いシリアル化をスケジュールする必要があります。また、PIM結合/プルーンメッセージなど、重要なバーストを作成できる他のPIMメッセージをバイパスする必要があります。
When there are no reception-triggered Assert/PackedAssert messages currently being serialized on the interface or scheduled to be sent, the router should immediately generate and schedule an Assert or PackedAssert message without further assert packing.
インターフェイスで現在シリアル化されている、または送信される予定である受信トリガーされたアサート/パックダッサートメッセージがない場合、ルーターはすぐにアサートまたはパックダッサートメッセージを生成してスケジュールする必要があります。
If one or more reception-triggered Assert/PackedAssert messages are already serializing or are scheduled to be serialized on the outgoing interface, then the router can use the time until the last of those messages has finished serializing for PIM processing of further conditions. This may result in additional reception-triggered assert records and the packing of these assert records without introducing additional delay.
1つ以上の受信トリガーされたAssert/PackedAssertメッセージがすでにシリアル化されているか、発信インターフェイスでシリアル化されるようにスケジュールされている場合、ルーターは、それらのメッセージの最後がさらなる条件のPIM処理のためにシリアル化が終了するまで時間を使用できます。これにより、追加の遅延を導入することなく、追加の受信トリガーされたアサートレコードとこれらのアサートレコードの梱包が発生する可能性があります。
Asserts triggered by expiry of the AT on an assert winner are not time-critical because they can be scheduled in advance and because the Assert_Override_Interval parameter [RFC7761] already creates a 3-second window in which such assert records can be sent, received, and processed before an assert loser's state expires and duplicate IP multicast packets could occur.
ATの有効期限がアサートの勝者によってトリガーされたアサートは、事前にスケジュールできるため、およびASSERT_OVERRIDE_INTERVALパラメーター[RFC7761]が既にそのようなASSTERTレコードを送信、受信し、受信できる3秒のウィンドウを作成しているため、時間的に批判的ではありません。アサート敗者の状態が期限切れになる前に処理され、IPマルチキャストパケットを複製する可能性があります。
An example mechanism to allow packing of AT expiry-triggered assert records on assert winners is to round the AT to an appropriate granularity such as 100 msec. This will cause the AT for multiple (S,G) and/or (*,G) states to expire at the same time, thus allowing them to be easily packed without changes to the Assert state machinery.
AT有効期限が切れているアサートレコードのアサート受賞者の梱包を可能にする例は、ATを100ミリ秒などの適切な粒度に丸めることです。これにより、ATが複数の（s、g）および/または（*、g）状態が同時に期限切れになるため、アサート状態の機械を変更せずに簡単に梱包できます。
AssertCancel messages have assert records with an infinite metric and can use assert packing like any other Assert. They are sent on Override Timer (OT) expiry and can be packed, for example, with the same considerations as AT expiry-triggered assert records.
AssertCancelメッセージには、無限のメトリックでアサートレコードがあり、他のアサートと同様にアサートパッキングを使用できます。それらはオーバーライドタイマー（OT）有効期限に送信され、たとえば、有効期限が切れたアサートレコードと同じ考慮事項で梱包できます。
Delay in sending PackedAsserts beyond what was discussed in prior subsections can still be beneficial when it causes the overall number of possible duplicate IP multicast packets to decrease in a situation with a large number of (S,G) and/or (*,G), compared to the situation where an implementation only sends Assert messages.
以前のサブセクションで議論されたものを超えてパックダッサートの送信の遅延は、重複するIPマルチキャストパケットの総数が多数の（s、g）および/または（*、g）の状況で減少する場合、依然として有益である可能性があります。、実装がアサートメッセージのみを送信する状況と比較してください。
This delay can be used in implementations because it cannot support the more advanced mechanisms described above, and this longer delay can be achieved by some simpler mechanisms (such as only periodic generation of PackedAsserts) and still achieves an overall reduction in duplicate IP multicast packets compared to sending only Asserts.
この遅延は、上記のより高度なメカニズムをサポートできないため、実装で使用できます。また、この長い遅延は、いくつかのより単純なメカニズム（周期生成のパッケダサートのみなど）によって実現でき、それでも重複IPマルチキャストパケットの全体的な減少を達成します。アサートのみを送信します。
When Asserts are sent, a single packet loss will result only in continued or new duplicates from a single IP multicast flow. Loss of a (non-AssertCancel) PackedAssert impacts duplicates for all flows packed into the PackedAssert and may result in the need for resending more than one Assert/PackedAssert, because of the possible inability to pack the assert records in this condition. Therefore, routers SHOULD support mechanisms that allow PackedAsserts and Asserts to be sent with an appropriate Differentiated Services Code Point (DSCP) [RFC2475] such as Expedited Forwarding (EF) to minimize their loss, especially when duplicate IP multicast packets could cause congestion and loss.
アサートが送信されると、単一のパケット損失は、単一のIPマルチキャストフローからの継続的または新しい重複のみになります。（アサートキャンセル以外の）パッケダサートの損失は、パッカサートに詰め込まれたすべてのフローの重複に影響を与え、この条件のアサート記録を詰めることができない可能性があるため、複数のアサート/パックダッサートを復活させる必要がある場合があります。したがって、ルーターは、適切な差別化されたサービスコードポイント（DSCP）[RFC2475]を使用してパッケダサートとアサートを可能にするメカニズムをサポートする必要があります。。
Routers MAY support a configurable option for sending PackedAssert messages twice in short order (such as 50 msec apart) to overcome possible loss, but only when the following two conditions are met.
ルーターは、パックダッサートメッセージを短い順序で2回送信するための構成可能なオプションをサポートして、損失の可能性を克服しますが、次の2つの条件が満たされた場合にのみです。
1. The total size of the two PackedAsserts is less than the total size of equivalent Assert messages.
1. 2つのパッケージャサートの合計サイズは、同等のアサートメッセージの合計サイズよりも少ないです。
2. The condition of the assert record flows in the PackedAssert is such that the router can expect that their reception by PIM routers will not trigger Assert/PackedAsserts replies. This condition is true, for example, when sending an assert record while becoming or being assert winner (Action A1/A3 in [RFC7761]).
2. パッケダサートのアサートレコードの流れの条件は、ルーターがPIMルーターによる受信がAssert/PackedAssertsの応答をトリガーしないことを期待できるようにします。この条件は、たとえば、勝者になったり、アサートの勝者になったりしているときにアサートレコードを送信するときに当てはまります（[RFC7761]のアクションA1/A3）。
The optimal target packing size will vary depending on factors including implementation characteristics and the required operating scale. At some point, as the target packing size is varied from the size of a single non-packed Assert to the MTU size, a size can be expected to be found where the router can achieve the required operating scale of (S,G) and (*,G) flows with minimum duplicates. Beyond this size, a further increase in the target packing size would not produce further benefits but might introduce possible negative effects such as the incurrence of more duplicates on loss.
最適なターゲットパッキングサイズは、実装特性や必要な動作スケールなどの要因によって異なります。ある時点で、ターゲットパッキングサイズは単一の非パックアサートのサイズからMTUサイズまで変化するため、ルーターが必要な動作スケール（s、g）と（s、g）と（s、g）と操作スケールを達成できる場合に、サイズが見つかると予想されます。（*、g）最小限の複製で流れます。このサイズを超えて、ターゲットパッキングサイズのさらなる増加はさらなる利点をもたらすことはありませんが、損失に対するより多くの重複の発生などの否定的な影響をもたらす可能性があります。
For example, in some router implementations, the total number of packets that a control plane function such as PIM can send/receive per unit of time is a more limiting factor than the total amount of data across these packets. As soon as the packet size is large enough for the maximum possible payload throughput, increasing the packet size any further may still reduce the processing overhead of the router but may increase latency incurred in creating the packet in a way that may increase duplicates compared to smaller packets.
たとえば、一部のルーターの実装では、PIMなどの制御プレーン関数が単位単位あたりの送信/受信できるパケットの総数は、これらのパケット全体のデータの総量よりも制限要因です。パケットサイズが可能な最大ペイロードスループットに十分な大きさになるとすぐに、パケットサイズをさらに増やすと、ルーターの処理オーバーヘッドが依存する可能性がありますが、パケットがより小さいと比較して重複する可能性のある方法で発生する潜在性が増加する可能性があります。パケット。
Upon reception of a PackedAssert message, the PIM router logically converts its payload into a sequence of assert records that are then processed as if an equivalent sequence of Assert messages were received according to [RFC7761].
PackedAssertメッセージを受信すると、PIMルーターはペイロードを論理的に一連のアサートレコードに変換し、[RFC7761]に従って同等のアサートメッセージのシーケンスを受信したかのように処理されます。
This section describes the format of new PIM extensions introduced by this document.
このセクションでは、このドキュメントで導入された新しいPIM拡張機能の形式について説明します。
The PIM Packed Assert Capability Hello Option is a new option for PIM Hello messages according to Section 4.9.2 of [RFC7761].
[RFC7761]のセクション4.9.2に従って、PIMパックアサート機能Hello Optionは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 = 40 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PIM Packed Assert Capability Hello Option
図1：PIMパックアサート機能Hello Option
OptionType 40 (Packed Assert Capability):
optionType 40（パックされたアサート機能）：
Indicates support for the ability to receive and process all the PackedAssert encodings defined in this document.
このドキュメントで定義されているすべてのパッカサートエンコーディングを受信および処理する機能のサポートを示します。
OptionLength 0:
Option -Length0：
The Packet Assert Capability has no OptionValue.
パケットアサート機能にはオプション数がありません。
Figure 2 shows a PIM Assert message as specified in Section 4.9.6 of [RFC7761]. The Encoded-Group and Encoded-Unicast address formats are specified in Section 4.9.1 of [RFC7761] for IPv4 and IPv6.
図2は、[RFC7761]のセクション4.9.6で指定されているPIMアサートメッセージを示しています。Encoded-GroupおよびEncoded-Unicastアドレス形式は、IPv4およびIPv6の[RFC7761]のセクション4.9.1で指定されています。
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 |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Assert Message Format
図2：メッセージ形式をアサートします
This common header shows the "7 6 5 4 3 2" flag bits (as defined in Section 4 of [RFC9436]) and the location of the P and A flags (as described in Section 5). As specified in Section 3.2, both flags in a (non-packed) PIM Assert message are required to be set to 0.
この一般的なヘッダーは、「7 6 5 4 3 2」フラグビット（[RFC9436のセクション4で定義されている）とPおよびAフラグの位置（セクション5で説明）を示しています。セクション3.2で指定されているように、（パックされていない）PIMアサートメッセージの両方のフラグを0に設定する必要があります。
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 |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Assert Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Assert Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Assert Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Simple PackedAssert Message Format
図3：シンプルなパッカサートメッセージ形式
PIM Version, Type, Checksum:
PIMバージョン、タイプ、チェックサム：
As specified in Section 4.9.6 of [RFC7761].
[RFC7761]のセクション4.9.6で指定されているとおり。
"7 6 5 4 3 2":
"7 6 5 4 3 2"：
Flag bits per Section 4 of [RFC9436].
[RFC9436]のセクション4ごとにフラグビット。
P:
P：
Packed flag. MUST be 1.
満員の旗。1でなければなりません。
A:
A：
Aggregated flag. MUST be 0.
集約されたフラグ。0でなければなりません。
Zero:
ゼロ：
Set to zero on transmission. Serves to make PIM routers that are not capable of assert packing to fail in parsing the message instead possible mis-parsing of the message as an Assert message [RFC7761] if this field was not zero-filled.
送信時にゼロに設定します。このフィールドがゼロ入っていない場合、アサートメッセージ[RFC7761]としてメッセージを誤って誤って誤って誤って並べる代わりに、メッセージを解析することに失敗することに失敗することができないPIMルーターを作成するのに役立ちます。
Reserved:
予約済み：
Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定します。受領時に無視されます。
M:
M：
The number of Assert Records in the message. Derived from the length of the packet carrying the message.
メッセージ内のアサートレコードの数。メッセージを運ぶパケットの長さから派生しました。
Assert Record:
アサートレコード：
Formatted according to Figure 3, which is the same as the PIM Assert message body as specified in Section 4.9.6 of [RFC7761].
図3に従ってフォーマットされています。これは、[RFC7761]のセクション4.9.6で指定されているように、PIMアサートメッセージ本文と同じです。
The format of each Assert Record is the same as the PIM Assert message body as specified in Section 4.9.6 of [RFC7761].
各アサートレコードの形式は、[RFC7761]のセクション4.9.6で指定されているように、PIMアサートメッセージ本文と同じです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Assert Record
図4：アサートレコード
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 |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Aggregated Assert Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Aggregated Assert Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Aggregated Assert Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Aggregated PackedAssert Message Format
図5：集約されたPackedAssertメッセージ形式
PIM Version, Type, Reserved, Checksum:
PIMバージョン、タイプ、予約、チェックサム：
As specified in Section 4.9.6 of [RFC7761].
[RFC7761]のセクション4.9.6で指定されているとおり。
"7 6 5 4 3 2":
"7 6 5 4 3 2"：
Flag bits per Section 4 of [RFC9436].
[RFC9436]のセクション4ごとにフラグビット。
P:
P：
Packed flag. MUST be 1.
満員の旗。1でなければなりません。
A:
A：
Aggregated flag. MUST be 1.
集約されたフラグ。1でなければなりません。
Zero:
ゼロ：
Set to zero on transmission. Serves to make PIM routers that are not capable of assert packing to fail in parsing the message instead possible mis-parsing of the message as an Assert message [RFC7761] if this field was not zero-filled.
送信時にゼロに設定します。このフィールドがゼロ入っていない場合、アサートメッセージ[RFC7761]としてメッセージを誤って誤って誤って誤って並べる代わりに、メッセージを解析することに失敗することに失敗することができないPIMルーターを作成するのに役立ちます。
Aggregated Assert Record:
集約されたアサートレコード：
Formatted according to Figure 5. The number M of Aggregated Assert Records is determined from the packet size.
図5に従ってフォーマットされています。集約されたアサートレコードの数は、パケットサイズから決定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Groups (N) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address N (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Source Aggregated Assert Record
図6：ソース集約されたアサートレコード
R:
R：
MUST be 0. R indicates both that the encoding format of the record is that of a Source Aggregated Assert Record and that all assert records represented by the Source Aggregated Assert Record have R=0 and are therefore (S,G) assert records according to the definition of R in [RFC7761], Section 4.9.6.
Rは0でなければなりません。Rは、レコードのエンコード形式がソース集約されたアサートレコードの形式であり、ソース集約されたアサートレコードで表されるすべてのアサートレコードがr = 0であり、したがって（s、g）assertレコードがあることを示します。[RFC7761]のRの定義、セクション4.9.6。
Metric Preference, Metric, Source Address:
メトリック選好、メトリック、ソースアドレス：
As specified in Section 4.9.6 of [RFC7761]. Source Address MUST NOT be zero.
[RFC7761]のセクション4.9.6で指定されているとおり。ソースアドレスがゼロであることはできません。
Number of Groups:
グループの数：
The number of Group Address fields.
グループアドレスフィールドの数。
Reserved:
予約済み：
Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定します。受領時に無視されます。
Group Address:
グループアドレス：
As specified in Section 4.9.6 of [RFC7761].
[RFC7761]のセクション4.9.6で指定されているとおり。
An RP Aggregation Assert Record aggregates (*,G) assert records with the same Metric Preference and Metric. Typically, this is the case for all (*,G) using the same RP, but the encoding is not limited to only (*,G) using the same RP because the RP address is not encoded as it is also not present in assert records [RFC7761].
RP集約は、同じメトリックの好みとメトリックでレコードをアサートします。通常、これは同じRPを使用しているすべての人（*、g）の場合ですが、エンコードは、RPアドレスがアサートにも存在しないためエンコードされていないため、同じRPを使用する（*、g）のみに限定されません。記録[RFC7761]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Group Records (K) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [K] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RP Aggregated Assert Record
図7：RP集約されたアサートレコード
R:
R：
MUST be 1. R indicates both that the encoding format of the record is that of an RP Aggregated Assert Record and that all assert records represented by the RP Aggregated Assert Record have R=1 and are therefore (*,G) assert records according to the definition of R in [RFC7761], Section 4.9.6.
1. rは、レコードのエンコード形式がRP集約されたアサートレコードの形式であり、RP集約されたアサートレコードで表されるすべてのアサートレコードがr = 1であり、したがって（*、g）アサートレコードであることの両方を示します。[RFC7761]のRの定義、セクション4.9.6。
Metric Preference, Metric:
メトリックの好み、メトリック：
As specified in Section 4.9.6 of [RFC7761].
[RFC7761]のセクション4.9.6で指定されているとおり。
Number of Group Records (K):
グループレコードの数（k）：
The number of packed Group Records. A record consists of a Group Address and a Source Address list with a number of sources.
パックされたグループレコードの数。レコードは、グループアドレスと多くのソースを備えたソースアドレスリストで構成されています。
Reserved:
予約済み：
Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定します。受領時に無視されます。
The format of each Group Record is:
各グループレコードの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sources (P) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address P (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Group Record
図8：グループレコード
Group Address:
グループアドレス：
As specified in Section 4.9.6 of [RFC7761].
[RFC7761]のセクション4.9.6で指定されているとおり。
Reserved:
予約済み：
Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定します。受領時に無視されます。
Number of Sources (P):
ソース数（P）：
The Number of Sources corresponds to the number of Source Address fields in the Group Record. If this number is not 0 and one of the (*,G) assert records to be encoded has Source Address 0, then 0 needs to be encoded as one of the Source Address fields.
ソースの数は、グループレコードのソースアドレスフィールドの数に対応しています。この数値が0ではなく、エンコードされる（*、g）アサートレコードの1つがソースアドレス0を持っている場合、ソースアドレスフィールドの1つとして0をエンコードする必要があります。
Reserved:
予約済み：
Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定します。受領時に無視されます。
Source Address:
ソースアドレス：
As specified in Section 4.9.6 of [RFC7761]. But there can be multiple Source Address fields in the Group Record.
[RFC7761]のセクション4.9.6で指定されているとおり。ただし、グループレコードには複数のソースアドレスフィールドがあります。
IANA has updated the "PIM Message Types" registry as follows to include the Packed and Aggregated flag bits for the Assert message type.
IANAは、「PIMメッセージタイプ」レジストリを次のように更新して、Assertメッセージタイプの梱包と集約のフラグビットを含めるようにしました。
+=======+========+==========================+===========+
| Value | Length | Name | Reference |
+=======+========+==========================+===========+
| 40 | 0 | Packed Assert Capability | RFC 9466 |
+-------+--------+--------------------------+-----------+
Table 1: PIM-Hello Options
表1：PIM-HELLOオプション
IANA has assigned the following two flag bits for PIM Assert messages in the "PIM Message Types" registry.
IANAは、「PIMメッセージタイプ」レジストリにPIMアサートメッセージに次の2つのフラグビットを割り当てました。
+======+========+=================+=====================+
| Type | Name | Flag Bits | Reference |
+======+========+=================+=====================+
| 5 | Assert | 0: Packed | RFC 9466 |
| | +-----------------+---------------------+
| | | 1: Aggregated | RFC 9466 |
| | +-----------------+---------------------+
| | | 2-7: Unassigned | [RFC3973] [RFC7761] |
+------+--------+-----------------+---------------------+
Table 2: PIM Message Types
表2：PIMメッセージタイプ
The security considerations of [RFC7761] apply to the extensions defined in this document.
[RFC7761]のセキュリティ上の考慮事項は、このドキュメントで定義されている拡張機能に適用されます。
This document packs multiple assert records in a single message. As described in Section 6.1 of [RFC7761], a forged Assert message could cause the legitimate designated forwarder to stop forwarding traffic to the LAN. The effect may be amplified when using a PackedAssert message.
このドキュメントは、単一のメッセージに複数のアサートレコードを詰め込みます。[RFC7761]のセクション6.1で説明されているように、偽造されたアサートメッセージにより、正当な指定されたフォワーダーがLANへのトラフィックの転送を停止する可能性があります。PackedAssertメッセージを使用すると、効果が増幅される場合があります。
Like other optional extensions of [RFC7761] that are active only when all routers indicate support for them, a single misconfigured or malicious router emitting forged PIM Hello messages can inhibit operations of this extension.
すべてのルーターがそれらのサポートを示している場合にのみアクティブな[RFC7761]の他のオプションの拡張機能と同様に、誤ったまたは悪意のあるルーターが鍛造PIMハローメッセージを放出することで、この拡張機能の操作を阻害できます。
Authentication of PIM messages, such as that explained in Sections 6.2 and 6.3 of [RFC7761], can protect against forged message attacks attacks.
[RFC7761]のセクション6.2および6.3で説明されているようなPIMメッセージの認証は、偽造されたメッセージ攻撃攻撃から保護できます。
[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>.
[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>.
[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>.
[RFC9436] Venaas, S. and A. Retana, "PIM Message Type Space
Extension and Reserved Bits", RFC 9436,
DOI 10.17487/RFC9436, August 2023,
<https://www.rfc-editor.org/info/rfc9436>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[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>.
[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
Systems' Solution for Multicast in BGP/MPLS IP VPNs",
RFC 6037, DOI 10.17487/RFC6037, October 2010,
<https://www.rfc-editor.org/info/rfc6037>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
The PIM Assert mechanism can only be avoided by designing the network to be without transit subnets with multiple upstream routers. For example, an L2 ring between routers can sometimes be reconfigured to be a ring of point-to-point subnets connected by the routers. However, these L2/L3 topology changes are undesirable when they are only done to enable IP multicast with PIM because they increase the cost of introducing IP multicast with PIM.
PIMアサートメカニズムは、複数の上流ルーターを備えたトランジットサブネットなしでネットワークを設計することによってのみ回避できます。たとえば、ルーター間のL2リングは、ルーターで接続されたポイントツーポイントサブネットのリングになるように再構成される場合があります。ただし、これらのL2/L3トポロジの変更は、IPマルチキャストをPIMで導入するコストを増加させるため、PIMでIPマルチキャストを有効にするためにのみ行われる場合、望ましくありません。
These L3 ring designs are specifically undesirable when particular L2 technologies are needed. For example, various L2 technologies for rings provide sub-50 msec failover mechanisms that will benefit IP unicast and multicast alike without any added complexity to the IP layer (forwarding or routing). If such L2 rings were to be replaced by L3 rings just to avoid PIM asserts, then this would result in the need for a complex choice of a sub-50 msec IP unicast failover solution (such as [RFC7490] with IP repair tunnels) as well as a separate sub-50 msec IP multicast failover solution, (such as [RFC7431] with dedicated ring support). The mere fact that, by running at the IP layer, different solutions for IP unicast and multicast are required makes them more difficult to operate, and they typically require more expensive hardware. This often leads to non-support of the IP multicast part.
これらのL3リングデザインは、特定のL2テクノロジーが必要な場合、特に望ましくありません。たとえば、リング用のさまざまなL2テクノロジーは、IPレイヤーに複雑さを加えずにIPユニキャストとマルチキャストの両方に利益をもたらすサブ50 MSECフェールオーバーメカニズムを提供します（転送またはルーティング）。そのようなL2リングをPIMのアサートを避けるためだけにL3リングに置き換えた場合、これにより、サブ50 MSEC IPユニキャストフェールオーバーソリューション（IP修復トンネルを備えた[RFC7490]など）の複雑な選択が必要になります。同様に、別のサブ50 MSEC IPマルチキャストフェールオーバーソリューション（専用のリングサポートを備えた[RFC7431など）。IPレイヤーで実行することにより、IPユニキャストとマルチキャストのさまざまなソリューションが必要であるという事実は、操作がより困難であり、通常はより高価なハードウェアが必要です。これは、多くの場合、IPマルチキャスト部品の非サポートにつながります。
Likewise, IEEE Time-Sensitive Networking mechanisms would require an L2 topology that cannot simply be replaced by an L3 topology. L2 sub-topologies can also significantly reduce the cost of deployment.
同様に、IEEEの時間依存ネットワーキングメカニズムには、L3トポロジに置き換えることはできないL2トポロジが必要です。L2サブトポロジーは、展開コストを大幅に削減することもできます。
The following subsections give examples of the type of network and use cases in which subnets with asserts have been observed or are expected to require scaling as provided by this specification.
以下のサブセクションは、ネットワークのタイプとユースケースの例を示しています。このケースでは、この仕様で提供されているように、アサートを持つサブネットが観察されるか、スケーリングが必要であると予想されます。
When an enterprise network is connected through an L2 network, the intra-enterprise runs L3 PIM multicast. The different sites of the enterprise are equivalent to the PIM connection through the shared LAN network. Depending upon the locations and number of groups, there could be many asserts on the first-hop routers.
エンタープライズネットワークがL2ネットワークを介して接続されている場合、エンテルプライズ内はL3 PIMマルチキャストを実行します。エンタープライズのさまざまなサイトは、共有LANネットワークを介したPIM接続と同等です。グループの場所と数に応じて、ファーストホップルーターには多くの主張がある可能性があります。
Video surveillance deployments have migrated from analog-based systems to IP-based systems oftentimes using multicast. In the shared LAN network deployments, when there are many cameras streaming to many groups, there may be issues with many asserts on first-hop routers.
ビデオ監視の展開は、マルチキャストを使用して、しばしばAnalogベースのシステムからIPベースのシステムに移行しました。共有LANネットワークの展開では、多くのグループに多くのカメラがストリーミングされている場合、最初のホップルーターに多くのアサートがある問題がある可能性があります。
Financial services extensively rely on IP Multicast to deliver stock market data and its derivatives, and the current multicast solution PIM is usually deployed. As the number of multicast flows grow, many stock data with many groups may result in many PIM asserts on a shared LAN network from the publisher to the subscribers.
金融サービスは、IPマルチキャストに広く依存して株式市場のデータとそのデリバティブを提供し、現在のマルチキャストソリューションPIMは通常展開されます。マルチキャストフローの数が増えると、多くのグループを持つ多くの在庫データが、パブリッシャーから加入者への共有LANネットワーク上で多くのPIMアサートをもたらす可能性があります。
PIM DR deployments are often used in host-side network for IPTV broadcast video services. Host-side access network failure scenarios may benefit from assert packing when many groups are being used. According to [RFC7761], the DR will be elected to forward multicast traffic in the shared access network. When the DR recovers from a failure, the original DR starts to send traffic, and the current DR is still forwarding traffic. In this situation, multicast traffic duplication maybe happen in the shared access network and can trigger the assert progress.
PIM DRの展開は、IPTVブロードキャストビデオサービスのホスト側ネットワークでよく使用されます。ホスト側のアクセスネットワーク障害シナリオは、多くのグループが使用されている場合のアサートパッキングの恩恵を受ける可能性があります。[RFC7761]によると、DRは共有アクセスネットワークのマルチキャストトラフィックを転送するように選出されます。博士が失敗から回復すると、元のDRはトラフィックの送信を開始し、現在のDRはまだトラフィックを転送しています。この状況では、マルチキャストトラフィックの複製が共有アクセスネットワークで発生する可能性があり、主張の進捗状況を引き起こす可能性があります。
As described in [RFC6037], Multicast Distribution Tree (MDT) is used as tunnels for Multicast VPN (MVPN). The configuration of multicast-enabled VPN Routing and Forwarding (VRF) or changes to an interface that is in a VRF may cause many assert packets to be sent at the same time.
[RFC6037]で説明されているように、マルチキャスト分布ツリー（MDT）は、マルチキャストVPN（MVPN）のトンネルとして使用されます。マルチキャスト対応のVPNルーティングと転送（VRF）の構成またはVRFにあるインターフェイスの変更により、多くのアサートパケットが同時に送信される可能性があります。
Additionally, future backhaul, or fronthaul, networks may want to connect L3 across an L2 underlay supporting Time-Sensitive Networks (TSNs). The infrastructure may run Deterministic Networking (DetNet) over TSN. These transit L2 LANs would have multiple upstreams and downstreams. This document takes a proactive approach to prevention of possible future assert issues in these types of environments.
さらに、将来のバックホール、またはFronthaulであるネットワークは、L3をL3をサポートする時間依存ネットワーク（TSNS）に接続したい場合があります。インフラストラクチャは、TSNを介して決定論的ネットワーク（DETNET）を実行する場合があります。これらのトランジットL2 LANには、複数の上流と下流があります。このドキュメントは、これらのタイプの環境で将来の可能性のある問題を防止するための積極的なアプローチを採用しています。
The authors would like to thank the following individuals: Stig Venaas for the valuable contributions of this document, Alvaro Retana for his thorough and constructive RTG AD review, Ines Robles for her Gen-ART review, Tommy Pauly for his Transport Area review, Robert Sparks for his SecDir review, Shuping Peng for her RtgDir review, John Scudder for his RTG AD review, Éric Vyncke for his INT AD review, Eric Kline for his INT AD review, Paul Wouter for his SEC AD review, Zaheduzzaman Sarker for his TSV AD review, Robert Wilton for his OPS AD review, and Martin Duke for his TSV AD review.
著者は、次の個人に感謝したいと思います。この文書の貴重な貢献については、彼の徹底的で建設的なRTG広告レビューのためのAlvaro Retana、彼女のGen-ArtレビューのためのInes Robles、彼の交通エリアレビューのTommy Pauly、Robert Sparks彼のsecdirレビュー、彼女のRTGDIRレビューのためのシュピングペン、彼のRTG広告レビューのためのジョン・スカダー、彼のint広告レビューのエリック・クライン、彼のSEC広告レビューのポール・ウェザー、彼のTSV広告のためのZaheduzzaman Sarkerのためのエリック・クラインのためにReview、Robert WiltonはOPS広告レビューのために、Martin DukeのTSV広告レビュー。
Yisong Liu (editor)
China Mobile
China
Email: liuyisong@chinamobile.com
Toerless Eckert (editor)
Futurewei
United States of America
Email: tte@cs.fau.de
Mike McBride
Futurewei
United States of America
Email: michael.mcbride@futurewei.com
Zheng (Sandy) Zhang
ZTE Corporation
China
Email: zhang.zheng@zte.com.cn