[要約] RFC 8775は、PIM（Protocol Independent Multicast）デザインエイテッドルーターの負荷分散に関するガイドラインです。その目的は、PIMネットワークでのデザインエイテッドルーターの負荷を均等に分散し、ネットワークのパフォーマンスを最適化することです。
Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 8775 H. Ou
Category: Standards Track Alibaba Group
ISSN: 2070-1721 S. Vallepalli
M. Mishra S. Venaas Cisco Systems, Inc. A. Green British Telecom April 2020
M. Mishra S. Venaas Cisco Systems、Inc. A. Green British Telecom 2020年4月
PIM Designated Router Load Balancing
PIM指定ルーターの負荷分散
Abstract
概要
On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.
マルチアクセスネットワークでは、PIM-SM（PIMスパースモード）ルーターの1つが指定ルーターとして選択されます。指定ルーターの役割の1つは、ローカルマルチキャストリスナーを追跡し、グループがPIM-SMで動作している場合は、これらのリスナーにデータを転送することです。このドキュメントでは、複数のPIM-SMルーターがこの責任を引き受けて転送負荷を複数のルーターに分散できるようにするPIM-SMプロトコルの変更について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8775.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8775で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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
2. Terminology
3. Applicability
4. Functional Overview
4.1. GDR Candidates
5. Protocol Specification
5.1. Hash Mask and Hash Algorithm
5.2. Modulo Hash Algorithm
5.2.1. Modulo Hash Algorithm Examples
5.2.2. Limitations
5.3. PIM Hello Options
5.3.1. PIM DR Load-Balancing Capability (DRLB-Cap) Hello
Option
5.3.2. PIM DR Load-Balancing List (DRLB-List) Hello Option
5.4. PIM DR Operation
5.5. PIM GDR Candidate Operation
5.6. DRLB-List Hello Option Processing
5.7. PIM Assert Modification
5.8. Backward Compatibility
6. Operational Considerations
7. IANA Considerations
7.1. Initial Registry
7.2. Assignment of New Hash Algorithms
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
On a multi-access LAN (such as an Ethernet) with one or more PIM-SM (PIM Sparse Mode) [RFC7761] routers, one of the PIM-SM routers is elected as a Designated Router (DR). The PIM DR has two responsibilities in the PIM-SM protocol. For any active sources on a LAN, the PIM DR is responsible for registering with the Rendezvous Point (RP) if the group is operating in PIM-SM. Also, the PIM DR is responsible for tracking local multicast listeners and forwarding data to these listeners if the group is operating in PIM-SM.
1つ以上のPIM-SM（PIMスパースモード）[RFC7761]ルーターを備えたマルチアクセスLAN（イーサネットなど）では、PIM-SMルーターの1つが指定ルーター（DR）として選出されます。 PIM DRには、PIM-SMプロトコルで2つの役割があります。 LAN上のアクティブなソースの場合、グループがPIM-SMで動作している場合、PIM DRはRendezvous Point（RP）への登録を担当します。また、グループがPIM-SMで動作している場合、PIM DRはローカルマルチキャストリスナーを追跡し、これらのリスナーにデータを転送します。
Consider the following LAN in Figure 1:
図1で次のLANを検討してください。
(core networks)
| | |
| | |
R1 R2 R3
| | |
----(LAN)----
|
|
(many receivers)
Figure 1: LAN with Receivers
図1：レシーバー付きLAN
Assume R1 is elected as the DR. According to the PIM-SM protocol, R1 will be responsible for forwarding traffic to that LAN on behalf of all local members. In addition to keeping track of membership reports, R1 is also responsible for initiating the creation of source and/or shared trees towards the senders or the RPs. The membership reports would be IGMP or Multicast Listener Discovery (MLD) messages. This applies to any versions of the IGMP and MLD protocols. The most recent versions are IGMPv3 [RFC3376] and MLDv2 [RFC3810].
R1がDRとして選出されたと想定します。 PIM-SMプロトコルによれば、R1はすべてのローカルメンバーに代わってそのLANにトラフィックを転送します。メンバーシップレポートを追跡することに加えて、R1は送信元またはRPへのソースおよび/または共有ツリーの作成を開始することも担当します。メンバーシップレポートは、IGMPまたはマルチキャストリスナーディスカバリ（MLD）メッセージです。これは、IGMPおよびMLDプロトコルのすべてのバージョンに適用されます。最新バージョンはIGMPv3 [RFC3376]とMLDv2 [RFC3810]です。
Having a single router acting as DR and being responsible for data-plane forwarding leads to several issues. One of the issues is that the aggregated bandwidth will be limited to what R1 can handle with regards to capacity of incoming links, the interface on the LAN, and total forwarding capacity. It is very common that a LAN consists of switches that run IGMP/MLD or PIM snooping [RFC4541]. This allows the forwarding of multicast packets to be restricted only to segments leading to receivers that have indicated their interest in multicast groups using either IGMP or MLD. The emergence of the switched Ethernet allows the aggregated bandwidth to exceed, sometimes by a large number, that of a single link. For example, let us modify Figure 1 and introduce an Ethernet switch in Figure 2.
1つのルーターがDRとして機能し、データプレーン転送を担当すると、いくつかの問題が発生します。問題の1つは、集約された帯域幅が、着信リンクの容量、LAN上のインターフェイス、および総転送容量に関してR1が処理できる帯域幅に制限されることです。 LANがIGMP / MLDまたはPIMスヌーピングを実行するスイッチで構成されることは非常に一般的です[RFC4541]。これにより、マルチキャストパケットの転送を、IGMPまたはMLDのいずれかを使用するマルチキャストグループへの関心を示している受信者につながるセグメントのみに制限できます。スイッチドイーサネットの出現により、集約された帯域幅は、単一のリンクの帯域幅を超える場合があり、それを超える場合があります。たとえば、図1を変更して、図2にイーサネットスイッチを導入します。
(core networks)
| | |
| | |
R1 R2 R3
| | |
+=gi1===gi2===gi3=+
+ +
+ switch +
+ +
+=gi4===gi5===gi6=+
| | |
H1 H2 H3
Figure 2: LAN with Ethernet Switch
図2：イーサネットスイッチを備えたLAN
Let us assume that each individual link is a Gigabit Ethernet. Each router (R1, R2, and R3) and the switch have enough forwarding capacity to handle hundreds of gigabits of data.
個々のリンクがギガビットイーサネットであると仮定します。各ルーター（R1、R2、およびR3）とスイッチには、数百ギガビットのデータを処理するのに十分な転送容量があります。
Let us further assume that each of the hosts requests 500 Mbps of unique multicast data. This totals to 1.5 Gbps of data, which is less than what each switch or the combined uplink bandwidth across the routers can handle, even under failure of a single router.
さらに、各ホストが500 Mbpsの一意のマルチキャストデータを要求するとします。これは合計1.5 Gbpsのデータであり、1台のルーターに障害が発生した場合でも、各スイッチまたはルーター全体のアップリンク帯域幅の合計が処理できるデータ量より少なくなります。
On the other hand, the link between R1 and switch, via port gi1, can only handle a throughput of 1 Gbps. And if R1 is the only DR (the PIM DR elected using the procedure defined by [RFC7761]), at least 500 Mbps worth of data will be lost because the only link that can be used to draw the traffic from the routers to the switch is via gi1. In other words, the entire network's throughput is limited by the single connection between the PIM DR and the switch (or LAN, as in Figure 1).
一方、ポートgi1を介したR1とスイッチ間のリンクは、1 Gbpsのスループットしか処理できません。そして、R1が唯一のDR（[RFC7761]で定義された手順を使用して選択されたPIM DR）である場合、ルーターからスイッチへのトラフィックの描画に使用できる唯一のリンクが原因で、少なくとも500 Mbps相当のデータが失われます。はgi1経由です。つまり、ネットワーク全体のスループットは、PIM DRとスイッチ（または図1のようにLAN）間の単一の接続によって制限されます。
Another important issue is related to failover. If R1 is the only forwarder on a shared LAN, when R1 goes out of service, multicast forwarding for the entire LAN has to be rebuilt by the newly elected PIM DR. However, if there were a way that allowed multiple routers to forward to the LAN for different groups, failure of one of the routers would only lead to disruption to a subset of the flows, therefore improving the overall resilience of the network.
もう1つの重要な問題は、フェイルオーバーに関連しています。 R1が共有LAN上の唯一のフォワーダーである場合、R1がサービスを停止すると、新しく選択されたPIM DRによってLAN全体のマルチキャスト転送を再構築する必要があります。ただし、複数のルーターが異なるグループのLANに転送できる方法があった場合、ルーターの1つに障害が発生してもフローのサブセットが中断するだけで、ネットワーク全体の回復力が向上します。
This document specifies a modification to the PIM-SM protocol that allows more than one of these routers, called Group Designated Routers (GDRs), to be selected so that the forwarding load can be distributed among a number of routers.
このドキュメントでは、グループ指定ルーター（GDR）と呼ばれるこれらのルーターを複数選択できるようにするPIM-SMプロトコルへの変更を指定し、転送負荷を複数のルーターに分散できるようにします。
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]で説明されているように解釈されます。
With respect to PIM-SM, this document follows the terminology that has been defined in [RFC7761].
PIM-SMに関しては、このドキュメントは[RFC7761]で定義されている用語に従います。
This document also introduces the following new acronyms:
このドキュメントでは、次の新しい頭字語も紹介しています。
GDR: Group Designated Router. For each multicast flow, either a (*,G) for Any-Source Multicast (ASM) or an (S,G) for Source-Specific Multicast (SSM) [RFC4607], a hash algorithm (described below) is used to select one of the routers as a GDR. The GDR is responsible for initiating the forwarding tree building process for the corresponding multicast flow.
GDR：グループ指定ルーター。マルチキャストフローごとに、Any-Source Multicast（ASM）の（*、G）またはSource-Specific Multicast（SSM）[RFC4607]の（S、G）、ハッシュアルゴリズム（以下で説明）を使用して、 GDRとしてのルーターの1つ。 GDRは、対応するマルチキャストフローの転送ツリー構築プロセスを開始します。
GDR Candidate: a router that has the potential to become a GDR. There might be multiple GDR Candidates on a LAN, but only one can become the GDR for a specific multicast flow.
GDR候補：GDRになる可能性のあるルーター。 LANには複数のGDR候補がある可能性がありますが、特定のマルチキャストフローのGDRになることができるのは1つだけです。
The extension specified in this document applies to PIM-SM routers acting as last-hop routers (there are directly connected receivers). It does not alter the behavior of a PIM DR or any other routers on the first-hop network (directly connected sources). This is because the source tree is built using the IP address of the sender, not the IP address of the PIM DR that sends PIM registers towards the RP. The load balancing between first-hop routers can be achieved naturally if an IGP provides equal cost multiple paths (which it usually does in practice). Also, distributing the load to do source registration does not justify the additional complexity required to support it.
このドキュメントで指定されている拡張機能は、ラストホップルーターとして機能するPIM-SMルーターに適用されます（受信機が直接接続されています）。ファーストホップネットワーク（直接接続されたソース）上のPIM DRまたはその他のルーターの動作は変更されません。これは、RPにPIMレジスタを送信するPIM DRのIPアドレスではなく、送信元のIPアドレスを使用してソースツリーが構築されるためです。 IGPが等コストの複数のパスを提供する場合（通常は実際にそれを行う）、ファーストホップルーター間のロードバランシングは自然に実現できます。また、ソース登録を行うために負荷を分散しても、それをサポートするために必要な追加の複雑さは正当化されません。
In the PIM DR election as defined in [RFC7761], when multiple routers are connected to a multi-access LAN (for example, an Ethernet), one of them is elected to act as PIM DR. The PIM DR is responsible for sending local Join/Prune messages towards the RP or source. In order to elect the PIM DR, each PIM router on the LAN examines the received PIM Hello messages and compares its own DR priority and IP address with those of its neighbors. The router with the highest DR priority is the PIM DR. If there are multiple such routers, their IP addresses are used as the tiebreaker, as described in [RFC7761].
[RFC7761]で定義されているPIM DR選出では、複数のルーターがマルチアクセスLAN（イーサネットなど）に接続されている場合、そのうちの1つがPIM DRとして機能するように選出されます。 PIM DRは、RPまたはソースに向けてローカルのJoin / Pruneメッセージを送信します。 PIM DRを選択するために、LAN上の各PIMルーターは受信したPIM Helloメッセージを調べ、自身のDR優先度とIPアドレスを近隣のDR優先度とIPアドレスと比較します。最も高いDR優先度を持つルーターはPIM DRです。そのようなルーターが複数ある場合、[RFC7761]で説明されているように、それらのIPアドレスがタイブレーカーとして使用されます。
In order to share forwarding load among last-hop routers, besides the normal PIM DR election, one or more GDRs are elected on the multi-access LAN. There is only one PIM DR on the multi-access LAN, but there might be multiple GDR Candidates.
ラストホップルータ間で転送負荷を共有するために、通常のPIM DR選出に加えて、1つ以上のGDRがマルチアクセスLANで選出されます。マルチアクセスLANにはPIM DRが1つしかありませんが、複数のGDR候補がある可能性があります。
For each multicast flow, that is, (*,G) for ASM and (S,G) for SSM, a hash algorithm (Section 5.1) is used to select one of the routers to be the GDR. The new DR Load-Balancing Capability (DRLB-Cap) PIM Hello Option is used to announce the Capability, as well as the hash algorithm type. Routers with the new DRLB-Cap Option advertised in their PIM Hello, using the same GDR election hash algorithm and the same DR priority as the PIM DR, are considered as GDR Candidates.
各マルチキャストフロー、つまりASMの（*、G）とSSMの（S、G）では、ハッシュアルゴリズム（セクション5.1）を使用して、ルーターの1つをGDRとして選択します。新しいDRロードバランシング機能（DRLB-Cap）PIM Hello Optionを使用して、機能とハッシュアルゴリズムタイプをアナウンスします。 PIM Helloでアドバタイズされた新しいDRLBキャップオプションを備えたルーターは、PIM DRと同じGDR選定ハッシュアルゴリズムと同じDR優先度を使用し、GDR候補と見なされます。
Hash masks are defined for Source, Group, and RP, separately, in order to handle PIM ASM/SSM. The masks, as well as a sorted list of GDR Candidate addresses, are announced by the DR in a new DR Load-Balancing List (DRLB-List) PIM Hello Option.
ハッシュマスクは、PIM ASM / SSMを処理するために、ソース、グループ、およびRPに対して個別に定義されます。マスクとGDR候補アドレスのソートされたリストは、DRによって新しいDRロードバランシングリスト（DRLB-List）PIM Helloオプションでアナウンスされます。
A hash algorithm based on the announced Source, Group, or RP masks allows one GDR to be assigned to a corresponding multicast state. That GDR is responsible for initiating the creation of the multicast forwarding tree for multicast traffic.
アナウンスされたソース、グループ、またはRPマスクに基づくハッシュアルゴリズムを使用すると、1つのGDRを対応するマルチキャストステートに割り当てることができます。そのGDRは、マルチキャストトラフィックのマルチキャスト転送ツリーの作成を開始します。
GDR is the new concept introduced by this specification. GDR Candidates are routers eligible for GDR election on the LAN. To become a GDR Candidate, a router must have the same DR priority and run the same GDR election hash algorithm as the DR on the LAN.
GDRは、この仕様で導入された新しい概念です。 GDR候補は、LAN上のGDR選出の対象となるルーターです。 GDR候補になるには、ルーターは同じDR優先度を持ち、LAN上のDRと同じGDR選定ハッシュアルゴリズムを実行する必要があります。
For example, assume there are 4 routers on the LAN: R1, R2, R3, and R4, each announcing a DRLB-Cap Option. R1, R2, and R3 have the same DR priority, while R4's DR priority is less preferred. In this example, R4 will not be eligible for GDR election, because R4 will not become a PIM DR unless all of R1, R2, and R3 go out of service.
たとえば、LANに4つのルーター、R1、R2、R3、およびR4があり、それぞれがDRLBキャップオプションを通知しているとします。 R1、R2、およびR3のDR優先度は同じですが、R4のDR優先度はあまり優先されません。この例では、R1、R2、およびR3のすべてがサービスを停止しない限り、R4はPIM DRにならないため、R4はGDR選出の対象にはなりません。
Furthermore, assume router R1 wins the PIM DR election, R1 and R2 advertise the same hash algorithm for GDR election, while R3 advertises a different one. In this case, only R1 and R2 will be eligible for GDR election, while R3 will not.
さらに、ルータR1がPIM DR選出に勝利し、R1とR2がGDR選出に同じハッシュアルゴリズムをアドバタイズし、R3が別のハッシュアルゴリズムをアドバタイズすると仮定します。この場合、R1とR2のみがGDR選出の対象になりますが、R3は対象外です。
As a DR, R1 will include its own Load-Balancing Hash Masks and the identity of R1 and R2 (the GDR Candidates) in its DRLB-List Hello Option.
DRとして、R1は独自の負荷分散ハッシュマスクと、R1およびR2（GDR候補）のIDをDRLBリストのHelloオプションに含めます。
A hash mask is used to extract a number of bits from the corresponding IP address field (32 for IPv4, 128 for IPv6) and calculate a hash value. A hash value is used to select a GDR from GDR Candidates advertised by the PIM DR. Hash masks allow for certain flows to always be forwarded by the same GDR, by ignoring certain bits in the hash value calculation, so that the hash values are the same. For example, 0.0.255.0 defines a hash mask for an IPv4 address that masks the first, second, and fourth octets, which means that only the third octet will influence the hash value computed. Note that the masks need not be a contiguous set of bits. For example, for IPv4, 15.15.15.15 would be a valid mask.
ハッシュマスクを使用して、対応するIPアドレスフィールド（IPv4の場合は32、IPv6の場合は128）からビット数を抽出し、ハッシュ値を計算します。ハッシュ値は、PIM DRによってアドバタイズされたGDR候補からGDRを選択するために使用されます。ハッシュマスクを使用すると、ハッシュ値の計算で特定のビットを無視することにより、特定のフローを常に同じGDRで転送できるため、ハッシュ値が同じになります。たとえば、0.0.255.0は、1番目、2番目、4番目のオクテットをマスクするIPv4アドレスのハッシュマスクを定義します。これは、3番目のオクテットのみが計算されるハッシュ値に影響を与えることを意味します。マスクは連続したビットのセットである必要はないことに注意してください。たとえば、IPv4の場合、15.15.15.15が有効なマスクになります。
In the text below, a hash mask is, in some places, said to be zero. A hash mask is zero if no bits are set, that is, 0.0.0.0 for IPv4 and :: for IPv6. Also, a hash mask is said to be an all-bits-set mask if it is 255.255.255.255 for IPv4 or ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff for IPv6.
以下のテキストでは、ハッシュマスクは、場合によってはゼロと言われています。ビットが設定されていない場合、ハッシュマスクはゼロです。つまり、IPv4の場合は0.0.0.0、IPv6の場合は::です。また、ハッシュマスクは、IPv4の場合は255.255.255.255、IPv6の場合はffff：ffff：ffff：ffff：ffff：ffff：ffff：ffffの場合、全ビットセットマスクと呼ばれます。
There are three hash masks defined:
3つのハッシュマスクが定義されています。
* RP Hash Mask
* RPハッシュマスク
* Source Hash Mask
* ソースハッシュマスク
* Group Hash Mask
* グループハッシュマスク
The hash masks need to be configured on the PIM routers that can potentially become a PIM DR, unless the implementation provides default hash mask values. An implementation SHOULD have default hash mask values as follows. The default RP Hash Mask SHOULD be zero (no bits set). The default Source and Group Hash Masks SHOULD both be all-bits-set masks. These default values are likely acceptable for most deployments and simplify configuration. There is only a need to use other masks if one needs to ensure that certain flows are forwarded by the same GDR.
実装がデフォルトのハッシュマスク値を提供しない限り、PIM DRになる可能性のあるPIMルーターでハッシュマスクを構成する必要があります。実装には、次のようなデフォルトのハッシュマスク値が必要です（SHOULD）。デフォルトのRPハッシュマスクはゼロ（ビットセットなし）である必要があります。デフォルトのソースおよびグループハッシュマスクは、両方とも全ビットセットマスクである必要があります（SHOULD）。これらのデフォルト値は、ほとんどの展開で許容できる可能性が高く、構成を簡素化します。特定のフローが同じGDRによって転送されるようにする必要がある場合にのみ、他のマスクを使用する必要があります。
The DRLB-List Hello Option contains a list of GDR Candidates. The first one listed has ordinal number 0, the second listed ordinal number 1, and the last one has ordinal number N - 1 if there are N candidates listed. The hash value computed will be the ordinal number of the GDR Candidate that is acting as GDR for the flow in question.
DRLBリストのHelloオプションには、GDR候補のリストが含まれています。リストされている最初の候補の序数は0、2番目の候補の序数は1、最後の候補はNの候補がある場合はN-1です。計算されるハッシュ値は、問題のフローのGDRとして機能しているGDR候補の序数になります。
The input to be hashed is determined as follows:
ハッシュされる入力は、次のように決定されます。
* If the group is in ASM mode and the RP Hash Mask announced by the PIM DR is not zero (at least one bit is set), calculate the value of hashvalue_RP (Section 5.2) to determine the GDR.
* グループがASMモードで、PIM DRによってアナウンスされたRPハッシュマスクがゼロでない場合（少なくとも1つのビットが設定されている場合）、hashvalue_RP（セクション5.2）の値を計算してGDRを決定します。
* If the group is in ASM mode and the RP Hash Mask announced by the PIM DR is zero (no bits are set), obtain the value of hashvalue_Group (Section 5.2) to determine the GDR.
* グループがASMモードで、PIM DRによってアナウンスされたRPハッシュマスクがゼロ（ビットが設定されていない）の場合、hashvalue_Group（セクション5.2）の値を取得してGDRを決定します。
* If the group is in SSM mode, use hashvalue_SG (Section 5.2) to determine the GDR.
* グループがSSMモードの場合は、hashvalue_SG（セクション5.2）を使用してGDRを決定します。
A simple modulo hash algorithm is defined in this document. However, to allow another hash algorithm to be used, a 1-octet "Hash Algorithm" field is included in the DRLB-Cap Hello Option to specify the hash algorithm used by the router.
このドキュメントでは、単純なモジュロハッシュアルゴリズムが定義されています。ただし、別のハッシュアルゴリズムを使用できるようにするために、1オクテットの「ハッシュアルゴリズム」フィールドがDRLB-Cap Helloオプションに含まれており、ルーターが使用するハッシュアルゴリズムを指定しています。
If different hash algorithms are advertised among the routers on a LAN, only the routers advertising the same hash algorithm as the DR (as well as having the same DR priority as the DR) are eligible for GDR election.
LAN上のルーター間で異なるハッシュアルゴリズムがアドバタイズされる場合、DRと同じハッシュアルゴリズムをアドバタイズする（およびDRと同じDR優先度を持つ）ルーターのみがGDR選出の対象になります。
As part of computing the hash, the notation LSZC(hash_mask) is used to denote the number of zeroes counted from the least significant bit of a hash mask hash_mask. As an example, LSZC(255.255.128) is 7 and LSZC(ffff:8000::) is 111. If all bits are set, LSZC will be 0. If the mask is zero, then LSZC will be 32 for IPv4 and 128 for IPv6.
ハッシュの計算の一部として、表記LSZC（hash_mask）は、ハッシュマスクhash_maskの最下位ビットからカウントされるゼロの数を示すために使用されます。例として、LSZC（255.255.128）は7で、LSZC（ffff：8000：:)は111です。すべてのビットが設定されている場合、LSZCは0になります。マスクがゼロの場合、IPv4および128のLSZCは32になりますIPv6の場合。
The number of GDR Candidates is denoted as GDRC.
GDR候補の数はGDRCとして示されます。
The idea behind the modulo hash algorithm is, in simple terms, that the corresponding mask is applied to a value, then the result is shifted right LSZC(mask) bits so that the least significant bits that were masked out are not considered. Then, this result is masked by 0xffffffff, keeping only the last 32 bits of the result (this only makes a difference for IPv6). Finally, the hash value is this result modulo the number of GDR Candidates (GDRC).
モジュロハッシュアルゴリズムの背後にある考え方は、簡単に言うと、対応するマスクが値に適用され、マスクされた最下位ビットが考慮されないように、結果が右LSZC（マスク）ビットにシフトされるということです。次に、この結果は0xffffffffによってマスクされ、結果の最後の32ビットのみを保持します（これにより、IPv6の場合にのみ違いが生じます）。最後に、ハッシュ値は、GDR候補（GDRC）の数を法とするこの結果です。
The modulo hash algorithm, for computing the values hashvalue_RP, hashvalue_Group, and hashvalue_SG, is defined as follows.
値hashvalue_RP、hashvalue_Group、およびhashvalue_SGを計算するためのモジュロハッシュアルゴリズムは、次のように定義されます。
hashvalue_RP is calculated as:
hashvalue_RPは次のように計算されます。
(((RP_address & RP_mask) >> LSZC(RP_mask)) & 0xffffffff) % GDRC
RP_address is the address of the RP defined for the group, and RP_mask is the RP Hash Mask.
RP_addressはグループに定義されたRPのアドレスであり、RP_maskはRPハッシュマスクです。
hashvalue_Group is calculated as:
hashvalue_Groupは次のように計算されます。
(((Group_address & Group_mask) >> LSZC(Group_mask)) & 0xffffffff)
% GDRC
Group_address is the group address, and Group_mask is the Group Hash Mask.
Group_addressはグループアドレスで、Group_maskはグループハッシュマスクです。
hashvalue_SG is calculated as:
hashvalue_SGは次のように計算されます。
((((Source_address & Source_mask) >> LSZC(Source_mask)) &
0xffffffff) ^ (((Group_address & Group_mask) >> LSZC(Group_mask))
& 0xffffffff)) % GDRC
Group_address is the group address, and Group_mask is the Group Hash Mask.
Group_addressはグループアドレスで、Group_maskはグループハッシュマスクです。
To help illustrate the algorithm, consider this example. Router X with IPv4 address 203.0.113.1 receives a DRLB-List Hello Option from the DR that announces RP Hash Mask 0.0.255.0 and a list of GDR Candidates, sorted by IP addresses from high to low: 203.0.113.3, 203.0.113.2, and 203.0.113.1. The ordinal number assigned to those addresses would be:
アルゴリズムの説明に役立つように、次の例を検討してください。 IPv4アドレス203.0.113.1のルーターXは、RPハッシュマスク0.0.255.0とGDR候補のリストをアナウンスするDRLB-List Hello Optionを受信し、IPアドレスの高い順に並べ替えます：203.0.113.3、203.0.113.2、および203.0.113.1。これらのアドレスに割り当てられる序数は次のようになります。
0 for 203.0.113.3; 1 for 203.0.113.2; 2 for 203.0.113.1 (Router X).
203.0.113.3の場合は0。 203.0.113.2の場合は1。 203.0.113.1（ルーターX）の場合は2。
Assume there are 2 RPs: RP1 192.0.2.1 for Group1 and RP2 198.51.100.2 for Group2. Following the modulo hash algorithm:
2つのRPがあると想定します。Group1のRP1 192.0.2.1とGroup2のRP2 198.51.100.2です。モジュロハッシュアルゴリズムに従います。
* LSZC(0.0.255.0) is 8, and GDRC is 3. The hashvalue_RP for Group1 with RP RP1 is:
* LSZC（0.0.255.0）は8、GDRCは3です。RPRP1のGroup1のhashvalue_RPは次のとおりです。
(((192.0.2.1 & 0.0.255.0) >> 8) & 0xffffffff % 3)
= 2 % 3
= 2
This matches the ordinal number assigned to Router X. Router X will be the GDR for Group1.
これは、ルーターXに割り当てられた序数と一致します。ルーターXは、Group1のGDRになります。
* The hashvalue_RP for Group2 with RP RP2 is:
* RP RP2を使用するGroup2のhashvalue_RPは次のとおりです。
(((198.51.100.2 & 0.0.255.0) >> 8) & 0xffffffff % 3)
= 100 % 3
= 1
This is different from the ordinal number of Router X (2). Hence, Router X will not be GDR for Group2.
これは、ルーターXの序数（2）とは異なります。したがって、ルーターXはGroup2のGDRにはなりません。
For IPv6, consider this example, similar to the above. Router X with IPv6 address fe80::1 receives a DRLB-List Hello Option from the DR that announces RP Hash Mask ::ffff:ffff:ffff:0 and a list of GDR Candidates, sorted by IP addresses from high to low: fe80::3, fe80::2, and fe80::1. The ordinal number assigned to those addresses would be:
IPv6については、上記と同様に、この例を検討してください。 IPv6アドレスfe80 :: 1のルーターXは、RPハッシュマスク:: ffff：ffff：ffff：0およびGDR候補のリストをアナウンスするDRからDRLB-List Hello Optionを受信し、IPアドレスの高い順に並べます：fe80 :: 3、fe80 :: 2、およびfe80 :: 1。これらのアドレスに割り当てられる序数は次のようになります。
0 for fe80::3; 1 for fe80::2; 2 for fe80::1 (Router X).
fe80 :: 3の場合は0。 fe80 :: 2の場合は1。 fe80 :: 1の場合は2（ルーターX）。
Assume there are 2 RPs: RP1 2001:db8::1:0:5678:1 for Group1 and RP2 2001:db8::1:0:1234:2 for Group2. Following the modulo hash algorithm:
2つのRPがあると想定します。RP12001：db8 :: 1：0：5678：1がGroup1で、RP2 2001：db8 :: 1：0：1234：2がGroup2です。モジュロハッシュアルゴリズムに従います。
* LSZC(::ffff:ffff:ffff:0) is 16, and GDRC is 3. The hashvalue_RP for Group1 with RP RP1 is:
* LSZC（:: ffff：ffff：ffff：0）は16、GDRCは3です。RPRP1のGroup1のhashvalue_RPは次のとおりです。
(((2001:db8::1:0:5678:1 & ::ffff:ffff:ffff:0) >> 16) &
0xffffffff % 3)
= ((::1:0:5678:0 >> 16) & 0xffffffff % 3)
= (::1:0:5678 & 0xffffffff % 3)
= ::5678 % 3
= 2
This matches the ordinal number assigned to Router X. Router X will be the GDR for Group1.
これは、ルーターXに割り当てられた序数と一致します。ルーターXは、Group1のGDRになります。
* The hashvalue_RP for Group2 with RP RP2 is:
* RP RP2を使用するGroup2のhashvalue_RPは次のとおりです。
(((2001:db8::1:0:1234:1 & ::ffff:ffff:ffff:0) >> 16) &
0xffffffff % 3)
= ((::1:0:1234:0 >> 16) & 0xffffffff % 3)
= (::1:0:1234 & 0xffffffff % 3)
= ::1234 % 3
= 1
This is different from the ordinal number of Router X (2). Hence, Router X will not be GDR for Group2.
これは、ルーターXの序数（2）とは異なります。したがって、ルーターXはGroup2のGDRにはなりません。
The modulo hash algorithm has poor failover characteristics when a shared LAN has more than two GDRs. In the case of more than two GDRs on a LAN, when one GDR fails, all of the groups may be reassigned to a different GDR, even if they were not assigned to the failed GDR. However, many deployments use only two routers on a shared LAN for redundancy purposes. Future work may define new hash algorithms where only groups assigned to the failed GDR get reassigned.
共有LANに3つ以上のGDRがある場合、モジュロハッシュアルゴリズムはフェイルオーバー特性が低くなります。 LANに3つ以上のGDRがある場合、1つのGDRに障害が発生すると、障害が発生したGDRにグループが割り当てられていなくても、すべてのグループが別のGDRに再割り当てされることがあります。ただし、多くの展開では、冗長性を確保するために、共有LAN上で2つのルーターのみを使用しています。将来の作業では、失敗したGDRに割り当てられたグループのみが再割り当てされる新しいハッシュアルゴリズムを定義する可能性があります。
The modulo hash algorithm will use, at most, 32 consecutive bits of the input addresses for its computation. Exactly which bits are used of the source, group, or RP addresses depend on the respective masks. This limitation may be an issue for IPv6 deployments, since not all bits of the IPv6 addresses are considered. If this causes operational issues, a new hash algorithm would need to be defined.
モジュロハッシュアルゴリズムは、計算に最大32ビットの連続した入力アドレスを使用します。送信元、グループ、またはRPアドレスのどのビットが使用されるかは、それぞれのマスクによって異なります。 IPv6アドレスのすべてのビットが考慮されるわけではないので、この制限はIPv6展開の問題である可能性があります。これにより運用上の問題が発生する場合は、新しいハッシュアルゴリズムを定義する必要があります。
PIM routers include a new option, called "Load-Balancing Capability (DRLB-Cap)", in their PIM Hello messages.
PIMルーターのPIM Helloメッセージには、「負荷分散機能（DRLB-Cap）」と呼ばれる新しいオプションが含まれています。
Besides this DRLB-Cap Hello Option, the elected PIM DR also includes a new "DR Load-Balancing List (DRLB-List) Hello Option". The DRLB-List Hello Option consists of three hash masks, as defined above, and also a list of GDR Candidate addresses on the LAN. It is recommended that the GDR Candidate addresses are sorted in descending order. This ensures that when using algorithms, such as the modulo hash algorithm in this document, that it is predictable which GDR is responsible for which groups, regardless of the order the DR learned about the candidates.
このDRLB-Cap Helloオプションに加えて、選出されたPIM DRには、新しい「DRロードバランシングリスト（DRLB-List）Helloオプション」も含まれています。 DRLBリストのHelloオプションは、上記で定義した3つのハッシュマスクと、LAN上のGDR候補アドレスのリストで構成されます。 GDR候補住所は降順で並べ替えることをお勧めします。これにより、このドキュメントのモジュロハッシュアルゴリズムなどのアルゴリズムを使用する場合、DRが候補について学習した順序に関係なく、どのGDRがどのグループを担当するかを予測できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 34 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PIM DR Load-Balancing Capability Hello Option
図3：PIM DRロードバランシング機能のHelloオプション
Type: 34
タイプ：34
Length: 4
長さ：4
Reserved: Transmitted as zero, ignored on receipt.
予約済み：ゼロとして送信され、受信時に無視されます。
Hash Algorithm: Hash algorithm type. A value listed in the IANA "PIM Designated Router Load-Balancing Hash Algorithms" registry. 0 is used for the hash algorithm defined in this document.
ハッシュアルゴリズム：ハッシュアルゴリズムのタイプ。 IANA「PIM Designated Router Load-Balancing Hash Algorithms」レジストリにリストされている値。このドキュメントで定義されているハッシュアルゴリズムには0が使用されます。
This DRLB-Cap Hello Option MUST be advertised by routers on all interfaces where DR Load Balancing is enabled. Note that the option is included, at most, once.
このDRLB-Cap Helloオプションは、DRロードバランシングが有効になっているすべてのインターフェイス上のルータによってアドバタイズされる必要があります。このオプションが含まれるのはせいぜい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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GDR Candidate Address(es) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PIM DR Load-Balancing List Hello Option
図4：PIM DRロードバランシングリストのHelloオプション
Type: 35
タイプ：35
Length: (3 + n) x (4 or 16) bytes, where n is the number of GDR Candidates.
長さ：（3 + n）x（4または16）バイト。nはGDR候補の数です。
Group Mask (32/128 bits): Mask applied to group addresses as part of hash computation.
グループマスク（32/128ビット）：ハッシュ計算の一部としてグループアドレスに適用されるマスク。
Source Mask (32/128 bits): Mask applied to source addresses as part of hash computation.
送信元マスク（32/128ビット）：ハッシュ計算の一部として送信元アドレスに適用されるマスク。
RP Mask (32/128 bits): Mask applied to RP addresses as part of hash computation.
RPマスク（32/128ビット）：ハッシュ計算の一部としてRPアドレスに適用されるマスク。
All masks MUST have the same number of bits as the IP source address in the PIM Hello IP header.
すべてのマスクは、PIM Hello IPヘッダーのIP送信元アドレスと同じビット数を持つ必要があります。
GDR Candidate Address(es) (32/128 bits): List of GDR Candidate(s)
All addresses MUST be in the same address family as the PIM Hello IP header. It is recommended that the addresses are sorted in descending order.
すべてのアドレスは、PIM Hello IPヘッダーと同じアドレスファミリーに属している必要があります。アドレスは降順にソートすることをお勧めします。
If the "Interface ID" option, as specified in [RFC6395], is present in a GDR Candidate's PIM Hello message and the "Router Identifier" portion is non-zero:
[RFC6395]で指定されている「インターフェースID」オプションがGDR候補のPIM Helloメッセージに存在し、「ルーター識別子」部分がゼロ以外の場合：
* For IPv4, the "GDR Candidate Address" will be set directly to the "Router Identifier".
* IPv4の場合、「GDR候補アドレス」は「ルーター識別子」に直接設定されます。
* For IPv6, the "GDR Candidate Address" will be 96 bits of zeroes, followed by the 32 bit Router Identifier.
* IPv6の場合、「GDR候補アドレス」は96ビットのゼロであり、その後に32ビットのルーター識別子が続きます。
If the "Interface ID" option is not present in a GDR Candidate's PIM Hello message or if the "Interface ID" option is present but the "Router Identifier" field is zero, the "GDR Candidate Address" will be the IPv4 or IPv6 source address of the PIM Hello message.
「インターフェースID」オプションがGDR候補のPIM Helloメッセージに存在しない場合、または「インターフェースID」オプションは存在するが「ルーター識別子」フィールドがゼロの場合、「GDR候補アドレス」はIPv4またはIPv6ソースになります。 PIM Helloメッセージのアドレス。
This DRLB-List Hello Option MUST only be advertised by the elected PIM DR. It MUST be ignored if received from a non-DR. The option MUST also be ignored if the hash masks are not the correct number of bits or GDR Candidate addresses are in the wrong address family.
このDRLBリストのHelloオプションは、選出されたPIM DRによってのみアドバタイズされる必要があります。非DRから受け取った場合は無視する必要があります。ハッシュマスクが正しいビット数でない場合、またはGDR候補アドレスが誤ったアドレスファミリーにある場合も、オプションを無視する必要があります。
The DR election process is still the same as defined in [RFC7761]. The DR advertises the new DRLB-List Hello Option, which contains mask values from user configuration (or default values), followed by a list of GDR Candidate addresses. Note that if a router included the "Interface ID" option in the hello message and the Router ID is non-zero, the Router ID will be used to form the GDR Candidate address of the router, as discussed in the previous section. It is recommended that the list be sorted from the highest value to the lowest value. The reason for sorting the list is to make the behavior deterministic, regardless of the order in which the DR learns of new candidates. Note that, as for non-DR routers, the DR also advertises the DRLB-Cap Hello Option to indicate its ability to support the new functionality and the type of GDR election hash algorithm it uses.
DR選出プロセスは、[RFC7761]で定義されているものと同じです。 DRは新しいDRLB-List Hello Optionをアドバタイズします。これには、ユーザー構成からのマスク値（またはデフォルト値）が含まれ、その後にGDR候補アドレスのリストが続きます。ルーターがhelloメッセージに「インターフェースID」オプションを含め、ルーターIDがゼロでない場合、前のセクションで説明したように、ルーターIDを使用してルーターのGDR候補アドレスが形成されます。リストは、最高値から最低値の順にソートすることをお勧めします。リストを並べ替える理由は、DRが新しい候補を学習する順序に関係なく、動作を確定的にするためです。非DRルーターの場合と同様に、DRはDRLB-Cap Hello Optionもアドバタイズし、新しい機能をサポートする能力と、使用するGDR選択ハッシュアルゴリズムのタイプを示します。
If a PIM DR receives a neighbor DRLB-Cap Hello Option that contains the same hash algorithm as the DR and the neighbor has the same DR priority as the DR, PIM DR SHOULD consider the neighbor as a GDR Candidate and insert the GDR Candidate's Address into the list of the DRLB-List Option. However, the DR may have policies limiting which or the number of GDR Candidates to include. Likewise, the DR SHOULD include itself in the list of GDR Candidates, but it is permissible not to do so, for instance, if there is some policy restricting the candidate set.
PIM DRがDRと同じハッシュアルゴリズムを含むネイバーDRLB-Cap Helloオプションを受信し、ネイバーがDRと同じDR優先度を持っている場合、PIM DRはそのネイバーをGDR候補と見なし、GDR候補のアドレスをに挿入する必要があります（SHOULD）。 DRLBリストオプションのリスト。ただし、DRには、含めるGDR候補の数または数を制限するポリシーがある場合があります。同様に、DRはGDR候補のリストに自分自身を含める必要があります（SHOULD）が、たとえば、候補セットを制限するポリシーがある場合は、そうしないことが許容されます。
If a PIM neighbor included in the list expires, stops announcing the DRLB-Cap Hello Option, changes DR priority, changes hash algorithm, or otherwise becomes ineligible as a candidate, the DR SHOULD immediately send a triggered hello with a new list in the DRLB-List option, excluding the neighbor.
リストに含まれるPIMネイバーが期限切れになる、DRLB-Cap Helloオプションの通知を停止する、DR優先度を変更する、ハッシュアルゴリズムを変更する、または候補として不適格になる場合、DR SHOULDはDRLBの新しいリストでトリガーされたHelloをすぐに送信する必要があります隣人を除く-Listオプション。
If a new router becomes eligible as a candidate, there is no urgency in sending out an updated list. An updated list SHOULD be included in the next hello.
新しいルーターが候補として適格になった場合、更新されたリストを送信する緊急性はありません。更新されたリストは、次のハローに含まれる必要があります。
When an IGMP/MLD report is received, a hash algorithm is used by the GDR Candidates to determine which router is going to be responsible for building forwarding trees on behalf of the host.
IGMP / MLDレポートを受信すると、GDR候補はハッシュアルゴリズムを使用して、ホストに代わって転送ツリーの構築を担当するルーターを決定します。
The router MUST include the DRLB-Cap Hello Option in all PIM Hello messages sent on the interface. Note that the presence of the DRLB-Cap Option in the PIM Hello does not guarantee that the router will be considered as a GDR Candidate. Once the DR election is done, the DRLB-List Hello Option is received from the current PIM DR containing a list of the selected GDR Candidates.
ルータは、インターフェイスで送信されるすべてのPIM HelloメッセージにDRLB-Cap Hello Optionを含める必要があります。 PIM HelloにDRLBキャップオプションが存在しても、ルータがGDR候補と見なされるとは限らないことに注意してください。 DRの選択が完了すると、DRLBリストのHelloオプションが、選択されたGDR候補のリストを含む現在のPIM DRから受信されます。
A router only acts as a GDR Candidate if it is included in the GDR Candidate list of the DRLB-List Hello Option. See next section for details.
ルータは、DRLBリストのHelloオプションのGDR候補リストに含まれている場合にのみ、GDR候補として機能します。詳細については、次のセクションを参照してください。
This section discusses processing of the DRLB-List Hello Option, including the case where it was received in the previous hello but not in the current hello. All routers MUST ignore the DRLB-List Hello Option if it is received from a PIM router that is not the DR. The option MUST only be processed by routers that are announcing the DRLB-Cap Option and only if the hash algorithm announced by the DR is the same as the local announcement. All GDR Candidates MUST use the hash masks advertised in the Option, even if they differ from those the candidate was configured with. The DR MUST also process its own DRLB-List Hello Option.
このセクションでは、前のhelloで受信されたが現在のhelloでは受信されなかった場合を含め、DRLBリストのHelloオプションの処理について説明します。すべてのルーターは、DRではないPIMルーターから受信した場合、DRLBリストのHelloオプションを無視する必要があります。このオプションは、DRLB-Capオプションをアナウンスするルーターによってのみ、およびDRによってアナウンスされるハッシュアルゴリズムがローカルアナウンスと同じである場合にのみ処理する必要があります。すべてのGDR候補は、候補が構成されたものと異なる場合でも、オプションでアドバタイズされるハッシュマスクを使用する必要があります。 DRは、独自のDRLBリストHelloオプションも処理する必要があります。
A router stores the latest option contents that were announced, if any, and deletes the previous contents. The router MUST also compare the new contents with any previous contents and, if there are any changes, continue processing as below. Note that if the option does not pass the above checks, the below processing MUST be done as if the option was not announced.
ルーターは、発表された最新のオプションコンテンツがあればそれを保存し、以前のコンテンツを削除します。ルーターはまた、新しいコンテンツを以前のコンテンツと比較し、変更がある場合は、以下のように処理を続行する必要があります。オプションが上記のチェックに合格しない場合、オプションがアナウンスされなかったかのように、以下の処理を実行する必要があることに注意してください。
If the contents of the DRLB-List Option, the masks, or the candidate list differ from the previously saved copy, it is received for the first time, or it is no longer being received or accepted, the option MUST be processed as below.
DRLBリストオプション、マスク、または候補リストの内容が以前に保存されたコピーと異なる場合、それが初めて受信されるか、受信または受信されなくなった場合、オプションは以下のように処理する必要があります。
1. If the local router is included in the "GDR Candidate Address(es)" field, it will look for its own address, or if it announces a non-zero Router ID, its own Router ID. For each of the groups or source and group pairs, if the group is in SSM mode with local receiver interest, the router MUST run the hash algorithm to determine which of them is for the GDR.
1. ローカルルーターが[GDR候補アドレス]フィールドに含まれている場合は、独自のアドレスを検索するか、ゼロ以外のルーターIDである独自のルーターIDをアナウンスします。グループまたはソースとグループのペアのそれぞれについて、グループがローカルレシーバー対象のSSMモードの場合、ルーターはハッシュアルゴリズムを実行して、GDRのグループを決定する必要があります。
* If there is no change in the GDR status, then no further action is required.
* GDRステータスに変更がない場合、それ以上のアクションは必要ありません。
* If the router becomes the new GDR, then a multicast forwarding tree MUST be built [RFC7761].
* ルーターが新しいGDRになる場合は、マルチキャスト転送ツリーを構築する必要があります[RFC7761]。
* If the router is no longer the GDR, then it uses an Assert as explained in Section 5.7.
* ルーターがGDRでなくなった場合は、セクション5.7で説明されているように、アサートを使用します。
2. If one of the following occurs:
2. 次のいずれかが発生した場合：
* the local router is not included in the "GDR Candidate Address(es)" field,
* ローカルルーターが[GDR候補アドレス]フィールドに含まれていない。
* the DRLB-List Hello Option is no longer included in the DR's Hello, or
* DRLBリストのHelloオプションがDRのHelloに含まれていない、または
* the DR's Neighbor Liveness Timer expires [RFC7761],
* DRのネイバー活性タイマーが期限切れになる[RFC7761]、
then for each group (or each source and group pair if the group is in SSM mode) with local receiver interest, for which the router is the GDR, the router uses an Assert as explained in Section 5.7.
次に、ルータがGDRであるローカルレシーバインタレストを持つ各グループ（またはグループがSSMモードの場合は各ソースとグループのペア）について、ルータはセクション5.7で説明されているアサートを使用します。
GDR changes may occur due to configuration change, GDR Candidates going down, and also new routers coming up and becoming GDR Candidates. This may occur while flows are being forwarded. If the GDR for an active flow changes, there is likely to be some disruption, such as packet loss or duplicates. By using asserts, packet loss is minimized while allowing a small amount of duplicates.
GDRの変更は、構成の変更、GDR候補のダウン、および新しいルーターが起動してGDR候補になるために発生する可能性があります。これは、フローの転送中に発生する可能性があります。アクティブフローのGDRが変更された場合、パケットの損失や重複など、何らかの障害が発生する可能性があります。アサートを使用することにより、少量の重複を許可しながら、パケット損失が最小限に抑えられます。
When a router stops acting as the GDR for a group, or source and group pair if SSM, it MUST set the Assert metric preference to maximum (0x7fffffff) and the Assert metric to one less than maximum (0xfffffffe). That is, whenever it sends or receives an Assert for the group, it must use these values as the metric preference and metric rather than the values provided by the unicast routing protocol.
ルーターがグループ、またはSSMの場合は送信元とグループのペアのGDRとしての機能を停止する場合、アサートメトリック設定を最大（0x7fffffff）に設定し、アサートメトリックを最大未満（0xfffffffe）に設定する必要があります。つまり、グループのアサートを送信または受信するときは常に、ユニキャストルーティングプロトコルによって提供される値ではなく、これらの値をメトリック設定およびメトリックとして使用する必要があります。
The rest of this section is just for illustration purposes and not part of the protocol definition.
このセクションの残りの部分は、説明のみを目的としており、プロトコル定義の一部ではありません。
To illustrate the behavior when there is a GDR change, consider the following scenario where there are two flows: G1 and G2. R1 is the GDR for G1, and R2 is the GDR for G2. When R3 comes up, it is possible that R3 becomes GDR for both G1 and G2; hence, R3 starts to build the forwarding tree for G1 and G2. If R1 and R2 stop forwarding before R3 completes the process, packet loss might occur. On the other hand, if R1 and R2 continue forwarding while R3 is building the forwarding trees, duplicates might occur.
GDRが変更されたときの動作を説明するために、G1とG2の2つのフローがある次のシナリオを考えます。 R1はG1のGDRで、R2はG2のGDRです。 R3が起動すると、R3がG1とG2の両方のGDRになる可能性があります。したがって、R3はG1とG2の転送ツリーの構築を開始します。 R3がプロセスを完了する前にR1とR2が転送を停止すると、パケット損失が発生する可能性があります。一方、R3が転送ツリーを構築している間にR1とR2が転送を続けると、重複が発生する可能性があります。
When the role of GDR changes as above, instead of immediately stopping forwarding, R1 and R2 continue forwarding to G1 and G2 respectively, while, at the same time, R3 build forwarding trees for G1 and G2. This will lead to PIM Asserts.
上記のようにGDRの役割が変わると、R1とR2は転送をすぐに停止するのではなく、それぞれG1とG2への転送を続行し、同時にR3はG1とG2の転送ツリーを構築します。これはPIMアサートにつながります。
For G1, using the functionality described in this document, R1 and R3 determine the new GDR, which is R3. With the modified Assert behavior, R1 sets its Assert metric to the near maximum value, as discussed above. That will make R3, which has normal metric in its Assert, the Assert winner.
G1の場合、このドキュメントで説明されている機能を使用して、R1とR3は新しいGDRであるR3を決定します。アサートの動作が変更されたため、R1はアサートメトリックを上記のように最大に近い値に設定します。これにより、アサートに通常のメトリックがあるR3がアサートの勝者になります。
In the case of a hybrid Ethernet shared LAN (where some PIM routers support the functionality defined in this document and some do not):
ハイブリッドイーサネット共有LANの場合（このドキュメントで定義されている機能をサポートしているPIMルーターとサポートしていないPIMルーターがあります）：
* If the DR does not support the new functionality, then there will be no load balancing.
* DRが新しい機能をサポートしていない場合、負荷分散は行われません。
* If non-DR routers do not support the new functionality, they will not be considered as GDR Candidate and will not take part in load balancing. Load balancing may still happen on the link.
* 非DRルーターが新しい機能をサポートしない場合、それらはGDR候補とは見なされず、負荷分散に参加しません。リンクで負荷分散が発生する可能性があります。
An administrator needs to consider what the total bandwidth requirements are and find a set of routers that together have enough available capacity while making sure that each of the routers can handle its part, assuming that the traffic is distributed roughly equally among the routers. Ideally, one should also have enough bandwidth to handle the case where at least one router fails. All routers should have reachability to the sources and RPs, if applicable, that are not via the LAN.
トラフィックがルーター間でほぼ均等に分散されていると想定して、管理者は合計帯域幅要件を検討し、十分な使用可能容量を備えたルーターのセットを見つけながら、各ルーターがその部分を処理できることを確認する必要があります。理想的には、少なくとも1つのルーターに障害が発生した場合に対応できる十分な帯域幅が必要です。すべてのルーターは、LANを介さないソースおよびRP（該当する場合）に到達可能でなければなりません。
Care must be taken when choosing what hash masks to configure. One would typically configure the same masks on all the routers so that they are the same, regardless of which router is elected as DR. The default masks are likely suitable for most deployment. The RP Hash Mask must be configured (the default is no bits set) if one wishes to hash based on the RP address rather than the group address for ASM. The default masks will use the entire group addresses, and source addresses if SSM, as part of the hash. An administrator may set other masks that mask out part of the addresses to ensure that certain flows always get hashed to the same router. How this is achieved depends on how the group addresses are allocated.
構成するハッシュマスクを選択するときは注意が必要です。通常、DRとして選択されたルーターに関係なく、すべてのルーターで同じマスクを構成して同じマスクにします。デフォルトのマスクは、ほとんどの展開に適しています。 ASMのグループアドレスではなくRPアドレスに基づいてハッシュする場合は、RPハッシュマスクを構成する必要があります（デフォルトではビットは設定されていません）。デフォルトのマスクは、ハッシュの一部として、グループアドレス全体と、SSMの場合は送信元アドレスを使用します。管理者は、アドレスの一部をマスクする他のマスクを設定して、特定のフローが常に同じルーターにハッシュされるようにすることができます。これがどのように達成されるかは、グループアドレスの割り当て方法によって異なります。
Only the routers announcing the same hash algorithm as the DR would be considered as GDR Candidates. Network administrators need to make sure that the desired set of routers announce the same algorithm. Migration between different algorithms is not considered in this document.
DRと同じハッシュアルゴリズムを通知するルーターのみがGDR候補と見なされます。ネットワーク管理者は、必要なルーターのセットが同じアルゴリズムを通知することを確認する必要があります。このドキュメントでは、異なるアルゴリズム間の移行については考慮していません。
IANA has made these assignments in the "PIM-Hello Options" registry: value 34 for the PIM DR Load-Balancing Capability (DRLB-Cap) Hello Option (with Length of 4), and value 35 for the PIM DR Load-Balancing List (DRLB-List) Hello Option (with variable Length).
IANAは、「PIM-Helloオプション」レジストリでこれらの割り当てを行いました。PIMDRロードバランシング機能（DRLB-Cap）Helloオプション（長さが4）の値34、およびPIM DRロードバランシングリストの値35 （DRLB-List）Helloオプション（可変長）。
Per this document, IANA has created a registry called "PIM Designated Router Load-Balancing Hash Algorithms" in the "Protocol Independent Multicast (PIM)" branch of the registry tree. The registry lists hash algorithms for use by PIM Designated Router Load Balancing.
このドキュメントに従って、IANAはレジストリツリーの「Protocol Independent Multicast（PIM）」ブランチに「PIM Designated Router Load-Balancing Hash Algorithms」と呼ばれるレジストリを作成しました。レジストリには、PIM指定ルーターロードバランシングで使用するハッシュアルゴリズムがリストされています。
The initial content of the registry is as follows.
レジストリの初期内容は以下の通りです。
+-------+------------+-----------+
| Type | Name | Reference |
+=======+============+===========+
| 0 | Modulo | RFC 8775 |
+-------+------------+-----------+
| 1-255 | Unassigned | |
+-------+------------+-----------+
Table 1
表1
Assignment of new hash algorithms is done according to the "IETF Review" procedure; see [RFC8126].
新しいハッシュアルゴリズムの割り当ては、「IETFレビュー」の手順に従って行われます。 [RFC8126]を参照してください。
Security of the new DR Load-Balancing PIM Hello Options is only guaranteed by the security of PIM Hello messages, so the security considerations for PIM Hello messages, as described in PIM-SM [RFC7761], apply here.
新しいDRロードバランシングPIM Helloオプションのセキュリティは、PIM Helloメッセージのセキュリティによってのみ保証されるため、PIM-SM [RFC7761]で説明されているPIM Helloメッセージのセキュリティに関する考慮事項がここに適用されます。
If the DR is subverted, it could omit or add certain GDRs or announce an unsupported algorithm. If another router is subverted, it could be made DR and cause similar issues. While these issues are specific to this specification, they are not that different from existing attacks, such as subverting a DR and lowering the DR priority, causing a different router to become the DR.
DRが破壊された場合、特定のGDRを省略または追加したり、サポートされていないアルゴリズムを通知したりする可能性があります。別のルーターが破壊された場合、それはDRになり、同様の問題を引き起こす可能性があります。これらの問題はこの仕様に固有のものですが、DRを覆し、DR優先度を下げ、別のルーターをDRにするなど、既存の攻撃とそれほど変わりません。
If, for any reason, the DR includes a GDR in the announced list that announces a different algorithm from what the DR announces, the GDR is required to ignore the announcement, and there will be no router acting as the DR for the flows that hash to that GDR.
何らかの理由で、DRがアナウンスしたリストとは異なるアルゴリズムをアナウンスするGDRがDRに含まれている場合、GDRはアナウンスを無視する必要があり、ハッシュするフローのDRとして機能するルーターはありません。そのGDRに。
If a GDR is subverted, it could potentially be made to stop forwarding all the traffic it is expected to forward. This is also similar today to if a DR is subverted.
GDRが破壊された場合、転送が予想されるすべてのトラフィックの転送を停止する可能性があります。これは、DRが破壊された場合も同様です。
An administrator may be able to achieve the desired load balancing of known flows, but an attacker may send a single high rate flow that is served by a single GDR or send multiple flows that are expected to be hashed to the same GDR.
管理者は既知のフローの望ましい負荷分散を達成できる可能性がありますが、攻撃者は単一のGDRによって処理される単一の高レートフローを送信するか、同じGDRにハッシュされることが予想される複数のフローを送信する可能性があります。
[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>。
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395, October 2011, <https://www.rfc-editor.org/info/rfc6395>.
[RFC6395] Gulrajani、S。およびS. Venaas、「An Interface Identifier（ID）Hello Option for PIM」、RFC 6395、DOI 10.17487 / RFC6395、2011年10月、<https://www.rfc-editor.org/info / rfc6395>。
[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、「Protocol Independent Multicast-Sparse Mode（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>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< https://www.rfc-editor.org/info/rfc3376>。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.
[RFC4541] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、DOI 10.17487 / RFC4541、2006年5月、 <https://www.rfc-editor.org/info/rfc4541>。
[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>。
Acknowledgements
謝辞
The authors would like to thank Steve Simlo and Taki Millonis for helping with the original idea; Alia Atlas, Bill Atwood, Joe Clarke, Alissa Cooper, Jake Holland, Bharat Joshi, Anish Kachinthaya, Anvitha Kachinthaya, Benjamin Kaduk, Mirja Kühlewind, Barry Leiba, Ben Niven-Jenkins, Alvaro Retana, Adam Roach, Michael Scharf, Éric Vyncke, and Carl Wallace for reviews and comments; and Toerless Eckert and Rishabh Parekh for helpful conversation on the document.
著者は、元のアイデアを支援してくれたSteve SimloとTaki Millonisに感謝します。 Alia Atlas、Bill Atwood、Joe Clarke、Alissa Cooper、Jake Holland、Bharat Joshi、Anish Kachinthaya、Anvitha Kachinthaya、Benjamin Kaduk、MirjaKühlewind、Barry Leiba、Ben Niven-Jenkins、Alvaro Retana、Adam Roach、Michael Scharf、Éカールウォレスのレビューとコメント。また、Toerless Eckert氏とRishabh Parekh氏は、この文書に関する有益な会話をしてくれました。
Authors' Addresses
著者のアドレス
Yiqun Cai Alibaba Group 520 Almanor Avenue Sunnyvale, CA 94085 United States of America
Y IグループCAIアリパパグループ520 ALマナーアベニューサニーベール、カリフォルニア州94085アメリカ合衆国
Email: yiqun.cai@alibaba-inc.com
Heidi Ou Alibaba Group 520 Almanor Avenue Sunnyvale, CA 94085 United States of America
Heidi Ou Alibaba Group 520 Almanor Avenueサニーベール、カリフォルニア州94085アメリカ合衆国
Email: heidi.ou@alibaba-inc.com
Sri Vallepalli
スリヴァッレパリ
Email: vallepal@yahoo.com
Mankamana Mishra Cisco Systems, Inc. 821 Alder Drive, Milpitas, CA 95035 United States of America
Mankamana Mishra Cisco Systems、Inc. 821 Alder Drive、Milpitas、CA 95035アメリカ合衆国
Email: mankamis@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
Andy Green British Telecom Adastral Park Ipswich IP5 2RE United Kingdom
Andy Green British Telecom Adastral Park Ipswich IP5 2REイギリス
Email: andy.da.green@bt.com