[要約] RFC 8220は、PIM（Protocol Independent Multicast）をVPLS（Virtual Private LAN Service）上で使用するためのガイドラインです。このRFCの目的は、VPLSネットワーク上でのマルチキャストトラフィックの効率的な配信を実現することです。
Internet Engineering Task Force (IETF) O. Dornon
Request for Comments: 8220 J. Kotalwar
Category: Informational V. Hemige
ISSN: 2070-1721 Nokia
R. Qiu
mistnet.io
Z. Zhang
Juniper Networks, Inc.
September 2017
Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)
仮想プライベートLANサービス（VPLS）上のプロトコル独立マルチキャスト（PIM）
Abstract
概要
This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.
このドキュメントでは、仮想プライベートLANサービス（VPLS）プロバイダーエッジ（PE）の手順と推奨事項について説明し、特定のポート（背後にProtocol Independent Multicast（PIM）ルーターまたはインターネットグループ管理プロトコル、あるいはその両方がある）へのマルチキャストトラフィックのレプリケーションを容易にします。 （IGMP）ホスト）PIMスヌーピングおよびプロキシ経由。
With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.
PIMスヌーピングを使用すると、PEは特定のPIM制御メッセージを受動的にリッスンして、それらのメッセージを透過的にフラッディングしながら、制御および転送状態を構築します。 PIMプロキシを使用すると、PEはPIM Join / Pruneメッセージをフラッディングせず、独自のメッセージを生成して、ダウンストリームのJoin / Pruneメッセージから構築された制御状態に基づいて特定のポートから送信するだけです。 PIMプロキシは、カスタマーエッジ（CE）デバイスでPIM加入抑制が有効になっている場合に必要であり、VPLSドメインのPIM制御トラフィックを削減するのに役立ちます。
This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.
このドキュメントでは、PIMリレーについても説明します。これは、すべてのダウンストリームのJoin / Pruneメッセージが特定のポートから転送されるだけでフラッディングされないため、CEデバイスでのPIM Join抑制のトリガーを回避できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8220.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8220で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Multicast Snooping in VPLS .................................5
1.2. Assumptions ................................................6
1.3. Definitions ................................................6
1.4. Requirements Language ......................................7
2. PIM Snooping for VPLS ...........................................7
2.1. PIM Protocol Background ....................................7
2.2. General Rules for PIM Snooping in VPLS .....................8
2.2.1. Preserving Assert Triggers ..........................8
2.3. Some Considerations for PIM Snooping .......................9
2.3.1. Scaling .............................................9
2.3.2. IPv4 and IPv6 ......................................10
2.3.3. PIM-SM (*,*,RP) ....................................10
2.4. PIM Snooping vs. PIM Proxying .............................10
2.4.1. Differences between PIM Snooping, Relay,
and Proxying .......................................10
2.4.2. PIM Control Message Latency ........................11
2.4.3. When to Snoop and When to Proxy ....................12
2.5. Discovering PIM Routers ...................................13
2.6. PIM-SM and PIM-SSM ........................................14
2.6.1. Building PIM-SM States .............................15
2.6.2. Explanation for Per-(S,G,N) States .................17
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages .........18
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages .........20
2.6.5. Receiving (S,G,rpt) Join/Prune Messages ............22
2.6.6. Sending Join/Prune Messages Upstream ...............23
2.7. Bidirectional PIM (BIDIR-PIM) .............................24
2.8. Interaction with IGMP Snooping ............................24
2.9. PIM-DM ....................................................25
2.9.1. Building PIM-DM States .............................25
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State
Machine ............................................25
2.9.3. Triggering Assert Election in PIM-DM ...............26
2.10. PIM Proxy ................................................26
2.10.1. Upstream PIM Proxy Behavior .......................26
2.11. Directly Connected Multicast Source ......................26
2.12. Data-Forwarding Rules ....................................27
2.12.1. PIM-SM Data-Forwarding Rules ......................28
2.12.2. PIM-DM Data-Forwarding Rules ......................29
3. IANA Considerations ............................................29
4. Security Considerations ........................................30
5. References .....................................................30
5.1. Normative References ......................................30
5.2. Informative References ....................................31
Appendix A. BIDIR-PIM Considerations ..............................32
A.1. BIDIR-PIM Data-Forwarding Rules ............................32
Appendix B. Example Network Scenario ..............................33
B.1. PIM Snooping Example .......................................33
B.2. PIM Proxy Example with (S,G) / (*,G) Interaction ...........36
Acknowledgements ..................................................42
Contributors ......................................................42
Authors' Addresses ................................................43
In the Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices provide a logical interconnect such that Customer Edge (CE) devices belonging to a specific VPLS instance appear to be connected by a single LAN. The Forwarding Information Base (FIB) for a VPLS instance is populated dynamically by Media Access Control (MAC) address learning. Once a unicast MAC address is learned and associated with a particular Attachment Circuit (AC) or pseudowire (PW), a frame destined to that MAC address only needs to be sent on that AC or PW.
仮想プライベートLANサービス（VPLS）では、プロバイダーエッジ（PE）デバイスは、特定のVPLSインスタンスに属するカスタマーエッジ（CE）デバイスが単一のLANによって接続されているように見えるような論理相互接続を提供します。 VPLSインスタンスの転送情報ベース（FIB）は、メディアアクセスコントロール（MAC）アドレスラーニングによって動的に入力されます。ユニキャストMACアドレスが学習され、特定の接続回線（AC）または疑似配線（PW）に関連付けられると、そのMACアドレス宛てのフレームは、そのACまたはPWでのみ送信される必要があります。
For a frame not addressed to a known unicast MAC address, flooding has to be used. This happens with the following so-called "BUM" (Broadcast, Unknown Unicast, and Multicast) traffic:
既知のユニキャストMACアドレスにアドレス指定されていないフレームの場合、フラッディングを使用する必要があります。これは、次のいわゆる「BUM」（ブロードキャスト、不明なユニキャスト、およびマルチキャスト）トラフィックで発生します。
o B: The destination MAC address is a broadcast address.
o B：宛先MACアドレスはブロードキャストアドレスです。
o U: The destination MAC address is unknown (has not been learned).
o U：宛先MACアドレスは不明です（学習されていません）。
o M: The destination MAC address is a multicast address.
o M：宛先MACアドレスはマルチキャストアドレスです。
Multicast frames are flooded because a PE cannot know where corresponding multicast group members reside. VPLS solutions (RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) perform replication for multicast traffic at the ingress PE devices. As stated in the VPLS Multicast Requirements document (RFC 5501 [VPLS-MCAST-REQ]), there are two issues with VPLS multicast today:
PEは対応するマルチキャストグループメンバーがどこにあるかを認識できないため、マルチキャストフレームはフラッディングされます。 VPLSソリューション（RFC 4762 [VPLS-LDP]およびRFC 4761 [VPLS-BGP]）は、入力PEデバイスでマルチキャストトラフィックのレプリケーションを実行します。 VPLSマルチキャスト要件ドキュメント（RFC 5501 [VPLS-MCAST-REQ]）で述べられているように、今日のVPLSマルチキャストには2つの問題があります。
1. Multicast traffic is replicated to non-member sites.
1. マルチキャストトラフィックは非メンバーサイトに複製されます。
2. Multicast traffic may be replicated when several PWs share a physical path.
2. 複数のPWが物理パスを共有している場合、マルチキャストトラフィックが複製されることがあります。
Issue 1 can be solved by multicast snooping -- PEs learn sites with multicast group members by snooping multicast protocol control messages on ACs and forward IP multicast traffic only to member sites. This document describes the procedures to achieve this when CE devices are PIM adjacencies of each other. Issue 2 is outside the scope of this document and is discussed in RFC 7117 [VPLS-MCAST].
問題1は、マルチキャストスヌーピングによって解決できます。PEは、AC上のマルチキャストプロトコル制御メッセージをスヌーピングすることにより、マルチキャストグループメンバーを持つサイトを学習し、IPマルチキャストトラフィックをメンバーサイトにのみ転送します。このドキュメントでは、CEデバイスが相互にPIM隣接である場合にこれを実現する手順について説明します。問題2はこのドキュメントの範囲外であり、RFC 7117 [VPLS-MCAST]で説明されています。
While descriptions in this document are in the context of the VPLS, the procedures also apply to regular Layer 2 switches interconnected by physical connections, except that the PW-related concepts and procedures do not apply in that case.
このドキュメントの説明はVPLSのコンテキストですが、手順は物理接続で相互接続された通常のレイヤ2スイッチにも適用されますが、PW関連の概念と手順はその場合には適用されません。
IGMP snooping procedures described in RFC 4541 [IGMP-SNOOP] make sure that IP multicast traffic is only sent on the following:
RFC 4541 [IGMP-SNOOP]で説明されているIGMPスヌーピング手順は、IPマルチキャストトラフィックが次のものでのみ送信されることを確認します。
o ACs connecting to hosts that report related group membership
o 関連するグループメンバーシップを報告するホストに接続するAC
o ACs connecting to routers that join related multicast groups
o 関連するマルチキャストグループに参加するルーターに接続するAC
o PWs connecting to remote PEs that have the above-described ACs
o 上記のACを持つリモートPEに接続するPW
Note that traffic is always sent on ports that have point-to-point connections to routers that are attached to a LAN on which there is at least one other router. Because IGMP snooping alone cannot determine if there are interested receivers beyond those routers, we always need to send traffic to these ports, even if there are no snooped group memberships. To further restrict traffic sent to those routers, PIM snooping can be used. This document describes the procedures for PIM snooping, including rules for when both IGMP and PIM snooping are enabled in a VPLS instance; see Sections 2.8 and 2.11 for details.
トラフィックは常に、少なくとも1つの他のルーターが存在するLANに接続されているルーターへのポイントツーポイント接続を持つポートで送信されることに注意してください。 IGMPスヌーピングだけでは、それらのルーターの向こう側に関係するレシーバーがあるかどうかを判別できないため、スヌーピングされたグループメンバーシップがない場合でも、常にこれらのポートにトラフィックを送信する必要があります。これらのルーターに送信されるトラフィックをさらに制限するには、PIMスヌーピングを使用できます。このドキュメントでは、VPLSインスタンスでIGMPとPIMスヌーピングの両方が有効になっている場合のルールを含む、PIMスヌーピングの手順について説明します。詳細については、セクション2.8および2.11を参照してください。
Note that for both IGMP and PIM, the term "snooping" is used loosely, referring to the fact that a Layer 2 device peeks into Layer 3 routing protocol messages to build relevant control and forwarding states. Depending on whether the control messages are transparently flooded, selectively forwarded, or aggregated, the processing may be called "snooping" or "proxying" in different contexts.
IGMPとPIMの両方で、「スヌーピング」という用語は大まかに使用されています。これは、レイヤ2デバイスがレイヤ3ルーティングプロトコルメッセージを調べて、関連する制御および転送状態を構築することを指します。制御メッセージが透過的にフラッディングされるか、選択的に転送されるか、または集約されるかに応じて、処理はさまざまなコンテキストで「スヌーピング」または「プロキシ」と呼ばれることがあります。
We will use the term "PIM snooping" in this document; however, unless explicitly noted otherwise, the procedures apply equally to PIM snooping and PIM proxying. The procedures specific to PIM proxying are described in Section 2.6.6. Differences that need to be observed while implementing one or the other and recommendations on which method to employ in different scenarios are noted in Section 2.4.
このドキュメントでは「PIMスヌーピング」という用語を使用します。ただし、特に明記されていない限り、手順はPIMスヌーピングとPIMプロキシに等しく適用されます。 PIMプロキシ固有の手順については、セクション2.6.6で説明します。どちらか一方を実装する際に注意する必要がある違いと、さまざまなシナリオでどの方法を採用するかについての推奨事項は、セクション2.4に記載されています。
This document also describes PIM relay, which can be viewed as lightweight PIM proxying. Unless explicitly noted otherwise, in the rest of this document proxying implicitly includes relay as well. Please refer to Section 2.4.1 for an overview of the differences between snooping, proxying, and relay.
このドキュメントでは、軽量のPIMプロキシとして表示できるPIMリレーについても説明します。特に明記されていない限り、このドキュメントの残りの部分では、プロキシには暗黙的にリレーも含まれます。スヌーピング、プロキシ、リレーの違いの概要については、セクション2.4.1を参照してください。
This document assumes that the reader has a good understanding of the PIM protocols. To help correlate the concepts and make the text easier to follow, this document is written in the same style as the following PIM RFCs:
このドキュメントは、読者がPIMプロトコルをよく理解していることを前提としています。概念を相互に関連付け、テキストをわかりやすくするために、このドキュメントは次のPIM RFCと同じスタイルで記述されています。
o RFC 3973 [PIM-DM]
o RFC 3973 [PIM-DM]
o RFC 4607 [PIM-SSM]
o RFC 4607 [PIM-SSM]
o RFC 5015 [BIDIR-PIM]
o KS 5015 [BaderBeam]
o RFC 5384 [JOIN-ATTR]
o RFC 5384 [JOIN-ATTR]
o RFC 7761 [PIM-SM]
o RFC 7761 [PIM-SM]
In order to avoid replicating text related to PIM protocol handling from the PIM RFCs, this document cross-references corresponding definitions and procedures in those RFCs. Deviations in protocol handling specific to PIM snooping are specified in this document.
PIM RFCからのPIMプロトコル処理に関連するテキストの複製を回避するために、このドキュメントでは、これらのRFCの対応する定義と手順を相互参照します。 PIMスヌーピングに固有のプロトコル処理の逸脱は、このドキュメントで指定されています。
There are several definitions referenced in this document that are well described in the following PIM RFCs: RFC 3973 [PIM-DM], RFC 5015 [BIDIR-PIM], and RFC 7761 [PIM-SM]. The following definitions and abbreviations are used throughout this document:
このドキュメントでは、次のPIM RFCで詳細に説明されているいくつかの定義があります。RFC3973 [PIM-DM]、RFC 5015 [BIDIR-PIM]、およびRFC 7761 [PIM-SM]。このドキュメントでは、次の定義と略語を使用しています。
o A port is defined as either an AC or a PW.
o ポートは、ACまたはPWとして定義されます。
o When we say that a PIM message is received on a PE port, it means that the PE is processing the message for snooping/proxying or relaying.
o PIMメッセージがPEポートで受信されたと言うとき、それはPEがスヌーピング/プロキシまたはリレーのためにメッセージを処理していることを意味します。
Abbreviations used in this document:
このドキュメントで使用される略語：
o S: IP address of the multicast source.
o S：マルチキャストソースのIPアドレス。
o G: IP address of the multicast group.
o G：マルチキャストグループのIPアドレス。
o N: Upstream Neighbor field in a Join/Prune/Graft message.
o N：Join / Prune / Graftメッセージのアップストリームネイバーフィールド。
o Port(N): Port on which neighbor N is learned, i.e., the port on which N's Hellos are received.
o Port（N）：ネイバーNが学習されるポート、つまりNのHelloが受信されるポート。
o rpt: Rendezvous Point Tree.
o rpt：ランデブーポイントツリー。
o PIM-DM: Protocol Independent Multicast - Dense Mode.
o PIM-DM：プロトコル非依存マルチキャスト-デンスモード。
o PIM-SM: Protocol Independent Multicast - Sparse Mode.
o PIM-SM：プロトコルに依存しないマルチキャスト-スパースモード。
o PIM-SSM: Protocol Independent Multicast - Source-Specific Multicast.
o PIM-SSM：Protocol Independent Multicast-Source-Specific Multicast。
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]で説明されているように解釈されます。
PIM is a multicast routing protocol running between routers, which are CE devices in a VPLS. It uses the unicast routing table to provide reverse-path information for building multicast trees. There are a few variants of PIM. As described in RFC 3973 [PIM-DM], multicast datagrams are pushed towards downstream neighbors, similar to a broadcast mechanism, but in areas of the network where there are no group members, routers prune back branches of the multicast tree towards the source. Unlike PIM-DM, other PIM flavors (RFC 7761 [PIM-SM], RFC 4607 [PIM-SSM], and RFC 5015 [BIDIR-PIM]) employ a pull methodology via explicit Joins instead of the push-and-prune technique.
PIMは、VPLS内のCEデバイスであるルーター間で実行されるマルチキャストルーティングプロトコルです。ユニキャストルーティングテーブルを使用して、マルチキャストツリーを構築するためのリバースパス情報を提供します。 PIMにはいくつかの変種があります。 RFC 3973 [PIM-DM]で説明されているように、マルチキャストデータグラムは、ブロードキャストメカニズムと同様に、ダウンストリームネイバーにプッシュされますが、グループメンバーが存在しないネットワークの領域では、ルーターはマルチキャストツリーのブランチをソースに向けてプルーニングします。 PIM-DMとは異なり、他のPIMフレーバー（RFC 7761 [PIM-SM]、RFC 4607 [PIM-SSM]、およびRFC 5015 [BIDIR-PIM]）は、プッシュアンドプルーン手法ではなく、明示的な結合によるプル手法を採用しています。 。
PIM routers periodically exchange Hello messages to discover and maintain stateful sessions with neighbors. After neighbors are discovered, PIM routers can signal their intentions to join or prune specific multicast groups. This is accomplished by having downstream routers send an explicit Join/Prune message (for the sake of generalization, consider Graft messages for PIM-DM as Join messages) to their corresponding upstream router. The Join/Prune message can be group specific (*,G) or group and source specific (S,G).
PIMルーターは定期的にHelloメッセージを交換して、ネイバーとのステートフルセッションを検出および維持します。ネイバーが検出されると、PIMルーターは、特定のマルチキャストグループに参加またはプルーニングする意思を通知できます。これは、ダウンストリームルータが明示的なJoin / Pruneメッセージを送信することで実現されます（一般化のために、PIM-DMのGraftメッセージをJoinメッセージとして検討します）。 Join / Pruneメッセージは、グループ固有（*、G）またはグループおよびソース固有（S、G）にすることができます。
The following rules for the correct operation of PIM snooping MUST be followed.
PIMスヌーピングの正しい動作については、次のルールに従う必要があります。
o PIM snooping MUST NOT affect the operation of customer Layer 2 protocols or Layer 3 protocols.
o PIMスヌーピングは、お客様のレイヤー2プロトコルまたはレイヤー3プロトコルの動作に影響を与えてはなりません。
o PIM messages and multicast data traffic forwarded by PEs MUST follow the split-horizon rule for mesh PWs, as defined in RFC 4762 [VPLS-LDP].
o PEによって転送されるPIMメッセージおよびマルチキャストデータトラフィックは、RFC 4762 [VPLS-LDP]で定義されているように、メッシュPWのスプリットホライズンルールに従う必要があります。
o PIM states in a PE MUST be per VPLS instance.
o PEのPIM状態は、VPLSインスタンスごとにある必要があります。
o PIM Assert triggers MUST be preserved to the extent necessary to avoid sending duplicate traffic to the same PE (see Section 2.2.1).
o PIMアサートトリガーは、同じPEへの重複トラフィックの送信を回避するために必要な範囲で保存する必要があります（セクション2.2.1を参照）。
In PIM-SM / PIM-DM, there are scenarios where multiple routers could be forwarding the same multicast traffic on a LAN. When this happens, these routers start the PIM Assert election process by sending PIM Assert messages, to ensure that only the Assert winner forwards multicast traffic on the LAN. The Assert election is a data-driven event and happens only if a router sees traffic on the interface to which it should be forwarding the traffic. In the case of a VPLS with PIM snooping, two routers may forward the same multicast datagrams at the same time, but each copy may reach a different set of PEs; this is acceptable from the point of view of avoiding duplicate traffic. If the two copies may reach the same PE, then the sending routers must be able to see each other's traffic, in order to trigger Assert election and stop duplicate traffic. To achieve that, PEs enabled with PIM-SSM / PIM-SM snooping MUST forward multicast traffic for an (S,G) / (*,G) not only on the ports on which they snooped Join(S,G) / Join(*,G) but also towards the upstream neighbor(s). In other words, the ports on which the upstream neighbors are learned must be added to the outgoing port list, along with the ports on which Joins are snooped. Please refer to Section 2.6.1 for the rules that determine the set of upstream neighbors for a particular (x,G).
PIM-SM / PIM-DMでは、複数のルーターがLAN上の同じマルチキャストトラフィックを転送するシナリオがあります。これが発生すると、これらのルーターはPIMアサートメッセージを送信してPIMアサート選定プロセスを開始し、アサートの勝者だけがLAN上のマルチキャストトラフィックを転送するようにします。アサート選択はデータ駆動型のイベントであり、ルータがトラフィックの転送先であるインターフェイスでトラフィックを検出した場合にのみ発生します。 PIMスヌーピングを使用するVPLSの場合、2つのルーターが同じマルチキャストデータグラムを同時に転送する可能性がありますが、各コピーは異なるPEのセットに到達する可能性があります。これは、トラフィックの重複を回避するという観点からは問題ありません。 2つのコピーが同じPEに到達する可能性がある場合、アサート選択をトリガーして重複するトラフィックを停止するために、送信側ルーターは互いのトラフィックを確認できる必要があります。これを実現するには、PIM-SSM / PIM-SMスヌーピングが有効になっているPEは、Join（S、G）/ Join（をスヌーピングしたポートだけでなく、（S、G）/（*、G）のマルチキャストトラフィックを転送する必要があります*、G）だけでなく、上流のネイバーに向けて。つまり、アップストリームネイバーが学習されるポートは、Joinがスヌーピングされるポートとともに、発信ポートリストに追加する必要があります。特定の（x、G）のアップストリームネイバーのセットを決定するルールについては、セクション2.6.1を参照してください。
Similarly, PIM-DM snooping SHOULD make sure that Asserts can be triggered (Section 2.9.3).
同様に、PIM-DMスヌーピングは、アサートをトリガーできることを確認する必要があります（セクション2.9.3）。
The above logic needs to be facilitated without breaking VPLS split-horizon forwarding rules. That is, traffic should not be forwarded on the port on which it was received, and traffic arriving on a PW MUST NOT be forwarded onto other PW(s).
上記のロジックは、VPLSスプリットホライズンフォワーディングルールに違反しないで促進する必要があります。つまり、トラフィックは受信されたポートで転送されるべきではなく、PWに到着するトラフィックは他のPWに転送されてはいけません。
The PIM snooping solution described here requires a PE to examine and operate on only PIM Hello and PIM Join/Prune packets. The PE does not need to examine any other PIM packets.
ここで説明するPIMスヌーピングソリューションでは、PEがPIM HelloパケットとPIM Join / Pruneパケットのみを調べて操作する必要があります。 PEは他のPIMパケットを検査する必要はありません。
Most of the PIM snooping procedures for handling Hello/Join/Prune messages are very similar to those executed in a PIM router. However, the PE does not need to have any routing tables like those required in PIM routing. It knows how to forward Join/Prune messages only by looking at the Upstream Neighbor field in the Join/Prune packets, as described in Section 2.12.
Hello / Join / Pruneメッセージを処理するためのPIMスヌーピング手順のほとんどは、PIMルーターで実行される手順とよく似ています。ただし、PEには、PIMルーティングで必要なテーブルのようなルーティングテーブルは必要ありません。セクション2.12で説明されているように、Join / PruneパケットのUpstream Neighborフィールドを確認するだけで、Join / Pruneメッセージを転送する方法がわかります。
The PE does not need to know about Rendezvous Points (RPs) and does not have to maintain any RP Set. All of that is transparent to a PIM snooping PE.
PEは、ランデブーポイント（RP）について知る必要はなく、RPセットを維持する必要もありません。これらはすべて、PIMスヌーピングPEに対して透過的です。
In the following subsections, we list some considerations and observations for the implementation of PIM snooping in the VPLS.
次のサブセクションでは、VPLSでのPIMスヌーピングの実装に関するいくつかの考慮事項と観察を示します。
PIM snooping needs to be employed on ACs at the downstream PEs (PEs receiving multicast traffic across the VPLS core) to prevent traffic from being sent out of ACs unnecessarily. PIM snooping techniques can also be employed on PWs at the upstream PEs (PEs receiving traffic from local ACs in a hierarchical VPLS) to prevent traffic from being sent to PEs unnecessarily. This may work well for small-scale or medium-scale deployments. However, if there are a large number of VPLS instances with a large number of PEs per instance, then the amount of snooping required at the upstream PEs can overwhelm the upstream PEs.
トラフィックがACから不必要に送信されないようにするには、PIMスヌーピングをダウンストリームPE（VPLSコアを介してマルチキャストトラフィックを受信するPE）のACで使用する必要があります。 PIMスヌーピング技術は、アップストリームPE（階層型VPLSのローカルACからトラフィックを受信するPE）のPWでも使用でき、トラフィックがPEに不必要に送信されるのを防ぎます。これは小規模または中規模の展開に適しています。ただし、インスタンスごとに多数のPEを持つ多数のVPLSインスタンスが存在する場合、アップストリームPEで必要なスヌーピングの量がアップストリームPEを圧倒する可能性があります。
There are two methods to reduce the burden on the upstream PEs. One is to use PIM proxying, as described in Section 2.6.6, to reduce the control messages forwarded by a PE. The other is not to snoop on the PWs at all but to have PEs signal the snooped states to other PEs out of band via BGP, as described in RFC 7117 [VPLS-MCAST]. In this document, it is assumed that snooping is performed on PWs.
アップストリームPEの負担を軽減する方法は2つあります。 1つは、セクション2.6.6で説明されているように、PIMプロキシを使用して、PEによって転送される制御メッセージを削減することです。もう1つは、PWをスヌーピングするのではなく、RFC 7117 [VPLS-MCAST]で説明されているように、BGP経由で帯域外のPEにスヌーピングされた状態をPEに通知させることです。このドキュメントでは、スヌーピングがPWで実行されることを前提としています。
In the VPLS, PEs forward Ethernet frames received from CEs and as such are agnostic of the Layer 3 protocol used by the CEs. However, as a PIM snooping PE, the PE would have to look deeper into the IP and PIM packets and build snooping state based on that. The PIM protocol specifications handle both IPv4 and IPv6. The specification for PIM snooping in this document can be applied to both IPv4 and IPv6 payloads.
VPLSでは、PEはCEから受信したイーサネットフレームを転送するため、CEで使用されるレイヤー3プロトコルに依存しません。ただし、PIMスヌーピングPEとして、PEはIPおよびPIMパケットをより深く調べ、それに基づいてスヌーピング状態を構築する必要があります。 PIMプロトコル仕様は、IPv4とIPv6の両方を処理します。このドキュメントのPIMスヌーピングの仕様は、IPv4とIPv6の両方のペイロードに適用できます。
This document does not address (*,*,RP) states in the VPLS network, as they have been removed from the PIM protocol as described in RFC 7761 [PIM-SM].
RFC 7761 [PIM-SM]で説明されているように、PIMプロトコルから削除されているため、このドキュメントではVPLSネットワークの（*、*、RP）状態については扱いません。
This document has previously alluded to PIM snooping/relay/proxying. Details on the PIM relay/proxying solution are discussed in Section 2.6.6. In this section, a brief description and comparison are given.
このドキュメントは、以前にPIMスヌーピング/リレー/プロキシについて言及しました。 PIMリレー/プロキシソリューションの詳細については、セクション2.6.6で説明します。このセクションでは、簡単な説明と比較を示します。
Differences between PIM snooping and relay/proxying can be summarized as follows:
PIMスヌーピングとリレー/プロキシの違いは、次のように要約できます。
+--------------------+---------------------+-----------------------+
| PIM snooping | PIM relay | PIM proxying |
+====================|=====================|=======================+
| Join/Prune messages| Join/Prune messages | Join/Prune messages |
| snooped and flooded| snooped; forwarded | consumed. Regenerated|
| according to VPLS | as is out of certain| ones sent out of |
| flooding procedures| upstream ports | certain upstream ports|
+--------------------+---------------------+-----------------------+
| Hello messages | Hello messages | Hello messages |
| snooped and flooded| snooped and flooded | snooped and flooded |
| according to VPLS | according to VPLS | according to VPLS |
| flooding procedures| flooding procedures | flooding procedures |
+--------------------+---------------------+-----------------------+
| No PIM packets | No PIM packets | New Join/Prune |
| generated | generated | messages generated |
+--------------------+---------------------+-----------------------+
| CE Join suppression| CE Join suppression | CE Join suppression |
| not allowed | allowed | allowed |
+--------------------+---------------------+-----------------------+
Other than the above differences, most of the procedures are common to PIM snooping and PIM relay/proxying, unless specifically stated otherwise.
上記の違いを除いて、特に明記されていない限り、ほとんどの手順はPIMスヌーピングとPIMリレー/プロキシに共通です。
Pure PIM snooping PEs simply snoop on PIM packets as they are being forwarded in the VPLS. As such, they truly provide transparent LAN services, since no customer packets are modified or consumed nor are new packets introduced in the VPLS. It is also simpler to implement than PIM proxying. However, for PIM snooping to work correctly, it is a requirement that CE routers MUST disable Join suppression in the VPLS. Otherwise, most of the CE routers with interest in a given multicast data stream will fail to send Join/Prune messages for that stream, and the PEs will not be able to tell which ACs and/or PWs have listeners for that stream.
純粋なPIMスヌーピングPEは、VPLSで転送されるPIMパケットを単純にスヌーピングします。そのため、VPLSでカスタマーパケットが変更または消費されることも、新しいパケットが導入されることもないため、透過的なLANサービスを提供します。また、PIMプロキシよりも実装が簡単です。ただし、PIMスヌーピングが正しく機能するためには、CEルータがVPLSの参加抑制を無効にする必要があることが要件です。そうでない場合、特定のマルチキャストデータストリームに関心のあるCEルータのほとんどは、そのストリームのJoin / Pruneメッセージの送信に失敗し、PEはどのACやPWにそのストリームのリスナーがあるかを通知できません。
Given that a large number of existing CE deployments do not support the disabling of Join suppression and given the operational complexity for a provider to manage the disabling of Join suppression in the VPLS, it becomes a difficult solution to deploy. Another disadvantage of PIM snooping is that it does not scale as well as PIM proxying. If there are a large number of CEs in a VPLS, then every CE will see every other CE's Join/Prune messages.
多数の既存のCE展開が参加抑制の無効化をサポートしていないこと、およびプロバイダーがVPLSでの参加抑制の無効化を管理する運用上の複雑さを考えると、展開は困難なソリューションになります。 PIMスヌーピングのもう1つの欠点は、PIMプロキシと同様に拡張できないことです。 VPLSに多数のCEがある場合、すべてのCEは他のすべてのCEの参加/プルーンメッセージを参照します。
PIM relay/proxying has the advantage that it does not require Join suppression to be disabled in the VPLS. Multicast as part of a VPLS can be very easily provided without requiring any changes on the CE routers. PIM relay/proxying helps scale VPLS multicast, since Join/Prune messages are only sent to certain upstream ports instead of flooded, and in cases of full proxying (vs. relay), the PEs intelligently generate only one Join/Prune message for a given multicast stream.
PIMリレー/プロキシには、VPLSで加入抑制を無効にする必要がないという利点があります。 VPLSの一部としてのマルチキャストは、CEルーターに変更を加えることなく、非常に簡単に提供できます。 Join / Pruneメッセージはフラッディングされるのではなく特定のアップストリームポートにのみ送信されるため、PIMリレー/プロキシはVPLSマルチキャストのスケーリングに役立ちます。フルプロキシ（vs.リレー）の場合、PEは所定の1つのJoin / Pruneメッセージのみをインテリジェントに生成します。マルチキャストストリーム。
PIM proxying, however, loses the transparency argument, since Join/Prune packets could get modified or even consumed at a PE. Also, new packets could get introduced in the VPLS. However, this loss of transparency is limited to PIM Join/Prune packets. It is in the interest of optimizing multicast in the VPLS and helping a VPLS network scale much better, for both the provider and the customer. Data traffic will still be completely transparent.
ただし、Join / PruneパケットがPEで変更されたり、PEで消費されたりする可能性があるため、PIMプロキシは透過性の引数を失います。また、新しいパケットがVPLSに導入される可能性があります。ただし、この透過性の損失は、PIMのJoin / Pruneパケットに限定されます。これは、プロバイダーとカスタマーの両方にとって、VPLSでマルチキャストを最適化し、VPLSネットワークのスケールを大幅に改善するのに役立ちます。データトラフィックは完全に透過的です。
A PIM snooping/relay/proxying PE snoops on PIM Hello packets while transparently flooding them in the VPLS. As such, there is no latency introduced by the VPLS in the delivery of PIM Hello packets to remote CEs in the VPLS.
PIMスヌーピング/リレー/プロキシPEは、PLS Helloパケットをスヌーピングし、VPLSで透過的にフラッディングします。そのため、VPLS内のリモートCEへのPIM Helloパケットの配信でVPLSによって導入される遅延はありません。
A PIM snooping PE snoops on PIM Join/Prune packets while transparently flooding them in the VPLS. There is no latency introduced by the VPLS in the delivery of PIM Join/Prune packets when PIM snooping is employed.
PIMスヌーピングPEはPIM加入/プルーニングパケットをスヌーピングし、VPLSで透過的にフラッディングします。 PIMスヌーピングが使用されている場合、PIM Join / Pruneパケットの配信でVPLSによって導入される遅延はありません。
A PIM relay/proxying PE does not simply flood PIM Join/Prune packets. This can result in additional latency for a downstream CE to receive multicast traffic after it has sent a Join. When a downstream CE prunes a multicast stream, the traffic SHOULD stop flowing to the CE with no additional latency introduced by the VPLS.
PIMリレー/プロキシPEは、単にPIM Join / Pruneパケットをフラッディングするだけではありません。これにより、Joinを送信した後、ダウンストリームCEがマルチキャストトラフィックを受信するための追加の遅延が発生する可能性があります。ダウンストリームCEがマルチキャストストリームをプルーニングするとき、トラフィックは、VPLSによって導入される追加のレイテンシなしでCEへのフローを停止する必要があります（SHOULD）。
Performing only proxying of Join/Prune and not Hello messages keeps the PE's behavior very similar to that of a PIM router, without introducing too much additional complexity. It keeps the PIM proxying solution fairly simple. Since Join/Prune messages are forwarded by a PE along the slow path and all other PIM packet types are forwarded along the fast path, it is very likely that packets forwarded along the fast path will arrive "ahead" of Join/Prune packets at a CE router (note the stress on the fact that fast-path messages will never arrive after Join/Prune packets). Of particular importance are Hello packets sent along the fast path. We can construct a variety of scenarios resulting in out-of-order delivery of Hellos and Join/Prune messages. However, there should be no deviation from normal expected behavior observed at the CE router receiving these messages out of order.
Join / Pruneのプロキシのみを実行し、Helloメッセージは実行しないことで、PEの動作はPIMルーターの動作と非常によく似たものになり、複雑さが増すことはありません。 PIMプロキシソリューションをかなりシンプルに保ちます。 Join / Pruneメッセージは低速パスに沿ってPEによって転送され、他のすべてのPIMパケットタイプは高速パスに沿って転送されるため、高速パスに沿って転送されたパケットは、Join / Pruneパケットの「先」に到着します。 CEルーター（ファストパスメッセージがJoin / Pruneパケットの後に到着しないという事実へのストレスに注意してください）。特に重要なのは、高速パスに沿って送信されるHelloパケットです。 HelloとJoin / Pruneメッセージの配信順序が乱れるさまざまなシナリオを構築できます。ただし、これらのメッセージを順不同で受信するCEルータで観察される通常の予想される動作からの逸脱があってはなりません。
From the above descriptions, factors that affect the choice of snooping/relay/proxying include:
上記の説明から、スヌーピング/リレー/プロキシの選択に影響を与える要因は次のとおりです。
o Whether CEs do Join suppression or not
o CEが加入抑制を行うかどうか
o Whether Join/Prune latency is critical or not
o Join / Pruneレイテンシが重要かどうか
o Whether the scale of PIM protocol messages/states in a VPLS requires the scaling benefit of proxying
o VPLSのPIMプロトコルメッセージ/状態のスケールにプロキシのスケーリングの利点が必要かどうか
Of the above factors, Join suppression is the hard one -- pure snooping can only be used when Join suppression is disabled on all CEs. The latency associated with relay/proxying is implementation dependent and may not be a concern at all with a particular implementation. The scaling benefit may not be important either, in that on a real LAN with Explicit Tracking (ET) a PIM router will need to receive and process all PIM Join/Prune messages as well.
上記の要因のうち、結合抑制は難しいものです。純粋なスヌーピングは、すべてのCEで結合抑制が無効になっている場合にのみ使用できます。リレー/プロキシに関連するレイテンシは実装依存であり、特定の実装ではまったく問題にならない場合があります。明示的な追跡（ET）を備えた実際のLANでは、PIMルーターがすべてのPIM Join / Pruneメッセージも受信して処理する必要があるため、スケーリングの利点も重要ではない場合があります。
A PIM router indicates that Join suppression is disabled if the T-bit is set in the LAN Prune Delay option of its Hello message. If all PIM routers on a LAN set the T-bit, ET is possible, allowing an upstream router to track all the downstream neighbors that have Join states for any (S,G) or (*,G). This has two benefits:
PIMルータは、HelloメッセージのLAN Prune DelayオプションでTビットが設定されている場合、参加抑制が無効であることを示します。 LAN上のすべてのPIMルーターがTビットを設定すると、ETが可能になり、上流ルーターは、（S、G）または（*、G）の結合状態を持つすべての下流ネイバーを追跡できます。これには2つの利点があります。
o No need for the Prune-Pending process -- the upstream router may immediately stop forwarding data when it receives a Prune from the last downstream neighbor and immediately prune to its upstream neighbor.
o Prune-Pendingプロセスは必要ありません。上流のルーターは、最後のダウンストリームネイバーからPruneを受信するとすぐにデータの転送を停止し、すぐにそのアップストリームネイバーにプルーニングします。
o For management purposes, the upstream router knows exactly which downstream routers exist for a particular Join state.
o 管理の目的で、上流ルーターは、特定の参加状態に存在する下流ルーターを正確に認識しています。
While full proxying can be used with or without Join suppression on CEs and does not interfere with an upstream CE's bypass of the Prune-Pending process, it does proxy all its downstream CEs as a single one to the upstream neighbors, removing the second benefit mentioned above.
フルプロキシは、CEでの結合抑制の有無にかかわらず使用でき、Prune-PendingプロセスのアップストリームCEのバイパスに干渉しませんが、ダウンストリームCEをすべて1つとしてアップストリームネイバーにプロキシし、前述の2番目の利点を取り除きます上記。
Therefore, the general rule is that if Join suppression is enabled on one or more CEs, then proxying or relay MUST be used, but if Join suppression is known to be disabled on all CEs, then snooping, relay, or proxying MAY be used, while snooping or relay SHOULD be used.
したがって、一般的なルールは、1つ以上のCEで結合抑制が有効になっている場合は、プロキシまたはリレーを使用する必要がありますが、すべてのCEで結合抑制が無効であることがわかっている場合は、スヌーピング、リレー、またはプロキシを使用できます。スヌーピングまたはリレーを使用する必要があります。
An implementation MAY choose to dynamically determine which mode to use, through the tracking of the above-mentioned T-bit in all snooped PIM Hello messages, or MAY simply require static provisioning.
実装は、すべてのスヌーピングされたPIM Helloメッセージの上記のTビットの追跡を通じて、使用するモードを動的に決定することを選択するか、単に静的プロビジョニングが必要になる場合があります。
A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs. That is, the PE transparently floods the PIM Hello while snooping on it. PIM Hellos are used by the snooping PE to discover PIM routers and their characteristics.
PIMスヌーピングPEは、ACおよびPWで受信したPIM Helloをスヌーピングする必要があります。つまり、PEはスヌーピング中にPIM Helloを透過的にフラッディングします。 PIM Helloは、PIMルーターとその特性を検出するためにスヌーピングPEによって使用されます。
For each neighbor discovered by a PE, it includes an entry in the PIM Neighbor Database with the following fields:
PEによって検出されたネイバーごとに、PIMネイバーデータベースに次のフィールドを持つエントリが含まれます。
o Layer 2 encapsulation for the router sending the PIM Hello.
o PIM Helloを送信するルータのレイヤ2カプセル化。
o IP address and address family of the router sending the PIM Hello.
o PIM Helloを送信するルータのIPアドレスとアドレスファミリ。
o Port (AC/PW) on which the PIM Hello was received.
o PIM Helloを受信したポート（AC / PW）。
o Hello Option fields.
o こんにちはオプションフィールド。
The PE should be able to interpret and act on Hello Option fields as currently defined in RFC 7761 [PIM-SM]. The Option fields of particular interest in this document are:
PEは、現在RFC 7761 [PIM-SM]で定義されているように、Hello Optionフィールドを解釈して処理できる必要があります。このドキュメントで特に興味深いオプションフィールドは次のとおりです。
o Hello-Hold-Time
o こんにちはホールドタイム
o Tracking Support
o 追跡サポート
o Designated Router (DR) Priority
o 指定ルーター（DR）の優先度
Please refer to RFC 7761 [PIM-SM] for a list of the Hello Option fields. When a PIM Hello is received, the PE MUST reset the neighbor-expiry-timer to Hello-Hold-Time. If a PE does not receive a Hello message from a router within Hello-Hold-Time, the PE MUST remove that neighbor from its PIM Neighbor Database. If a PE receives a Hello message from a router with the Hello-Hold-Time value set to zero, the PE MUST remove that router from the PIM snooping state immediately.
Hello Optionフィールドのリストについては、RFC 7761 [PIM-SM]を参照してください。 PIM Helloを受信すると、PEはneighbor-expiry-timerをHello-Hold-Timeにリセットする必要があります。 PEがHello-Hold-Time内にルーターからHelloメッセージを受信しない場合、PEはそのネイバーをPIMネイバーデータベースから削除する必要があります。 PEがHello-Hold-Time値をゼロに設定したルーターからHelloメッセージを受信した場合、PEはそのルーターをPIMスヌーピング状態からすぐに削除する必要があります。
From the PIM Neighbor Database, a PE MUST be able to use the procedures defined in RFC 7761 [PIM-SM] to identify the PIM DR in the VPLS instance. It should also be able to determine if tracking support is active in the VPLS instance.
PIMネイバーデータベースから、PEはRFC 7761 [PIM-SM]で定義された手順を使用して、VPLSインスタンスのPIM DRを識別できる必要があります。また、VPLSインスタンスでトラッキングサポートがアクティブかどうかを判別できる必要もあります。
The key characteristic of PIM-SM and PIM-SSM is explicit Join behavior. In this model, multicast traffic is only forwarded to locations that specifically request it. All the procedures described in this section apply to both PIM-SM and PIM-SSM, except for the fact that there is no (*,G) state in PIM-SSM.
PIM-SMおよびPIM-SSMの主要な特性は、明示的な結合動作です。このモデルでは、マルチキャストトラフィックは、特別に要求する場所にのみ転送されます。このセクションで説明するすべての手順は、PIM-SSMに（*、G）状態がないことを除いて、PIM-SMとPIM-SSMの両方に適用されます。
PIM-SM and PIM-SSM states are built by snooping on the PIM-SM Join/Prune messages received on ACs/PWs.
PIM-SMおよびPIM-SSMの状態は、AC / PWで受信されたPIM-SM Join / Pruneメッセージをスヌーピングすることによって構築されます。
The downstream state machine of a PIM-SM snooping PE very closely resembles the downstream state machine of PIM-SM routers. The downstream state consists of:
PIM-SMスヌーピングPEのダウンストリームステートマシンは、PIM-SMルータのダウンストリームステートマシンに非常によく似ています。ダウンストリーム状態は次のもので構成されます。
Per downstream (Port,*,G):
ダウンストリームごと（ポート、*、G）：
o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o DownstreamJPState：{"NoInfo"（NI）、 "Join"（J）、 "Prune-Pending"（PP）}のいずれか
Per downstream (Port,*,G,N):
ダウンストリームごと（ポート、*、G、N）：
o Prune-Pending Timer (PPT(N))
o プルーン保留タイマー（PPT（N））
o Join Expiry Timer (ET(N))
o 有効期限タイマーに参加（ET（N））
Per downstream (Port,S,G):
ダウンストリームごと（ポート、S、G）：
o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o DownstreamJPState：{"NoInfo"（NI）、 "Join"（J）、 "Prune-Pending"（PP）}のいずれか
Per downstream (Port,S,G,N):
ダウンストリームごと（ポート、S、G、N）：
o Prune-Pending Timer (PPT(N))
o プルーン保留タイマー（PPT（N））
o Join Expiry Timer (ET(N))
o 有効期限タイマーに参加（ET（N））
Per downstream (Port,S,G,rpt):
ダウンストリームごと（ポート、S、G、rpt）：
o DownstreamJPRptState: One of {"NoInfo" (NI), "Pruned" (P), "Prune-Pending" (PP)}
o DownstreamJPRptState：{"NoInfo"（NI）、 "Pruned"（P）、 "Prune-Pending"（PP）}のいずれか
Per downstream (Port,S,G,rpt,N):
ダウンストリームごと（ポート、S、G、rpt、N）：
o Prune-Pending Timer (PPT(N))
o プルーン保留タイマー（PPT（N））
o Join Expiry Timer (ET(N))
o 有効期限タイマーに参加（ET（N））
where S is the address of the multicast source, G is the group address, and N is the Upstream Neighbor field in the Join/Prune message.
ここで、Sはマルチキャストソースのアドレス、Gはグループアドレス、NはJoin / Pruneメッセージのアップストリームネイバーフィールドです。
Note that unlike the case of PIM-SM routers, where the PPT and ET are per (Interface,S,G), PIM snooping PEs have to maintain the PPT and ET per (Port,S,G,N). The reasons for this are explained in Section 2.6.2.
PIMとETが（インターフェイス、S、G）ごとにあるPIM-SMルーターの場合とは異なり、PIMスヌーピングPEは（ポート、S、G、N）ごとにPPTとETを維持する必要があることに注意してください。この理由については、セクション2.6.2で説明します。
Apart from the above states, we define the following state summarization macros:
上記の状態とは別に、次の状態要約マクロを定義します。
UpstreamNeighbors(*,G): If there are one or more Join(*,G)s received on any port with upstream neighbor N and ET(N) is active, then N is added to UpstreamNeighbors(*,G). This set is used to determine if a Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent upstream.
UpstreamNeighbors（*、G）：アップストリームネイバーNのポートで1つ以上のJoin（*、G）が受信され、ET（N）がアクティブな場合、NがUpstreamNeighbors（*、G）に追加されます。このセットは、アップストリームネイバーNとのJoin（*、G）またはPrune（*、G）をアップストリームに送信する必要があるかどうかを決定するために使用されます。
UpstreamNeighbors(S,G): If there are one or more Join(S,G)s received on any port with upstream neighbor N and ET(N) is active, then N is added to UpstreamNeighbors(S,G). This set is used to determine if a Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent upstream.
UpstreamNeighbors（S、G）：アップストリームネイバーNのポートで1つ以上のJoin（S、G）が受信され、ET（N）がアクティブな場合、NがUpstreamNeighbors（S、G）に追加されます。このセットは、アップストリームネイバーNとのJoin（S、G）またはPrune（S、G）をアップストリームに送信する必要があるかどうかを決定するために使用されます。
UpstreamPorts(*,G): This is the set of all Port(N) ports where N is in the set UpstreamNeighbors(*,G). Multicast streams forwarded using a (*,G) match MUST be forwarded to these ports. So, UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G).
UpstreamPorts（*、G）：これは、NがUpstreamNeighbors（*、G）のセットにあるすべてのPort（N）ポートのセットです。 （*、G）マッチを使用して転送されるマルチキャストストリームは、これらのポートに転送される必要があります。したがって、UpstreamPorts（*、G）をOutgoingPortList（*、G）に追加する必要があります。
UpstreamPorts(S,G): This is the set of all Port(N) ports where N is in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added to OutgoingPortList(S,G).
UpstreamPorts（S、G）：これは、NがUpstreamNeighbors（S、G）のセットにあるすべてのPort（N）ポートのセットです。 UpstreamPorts（S、G）をOutgoingPortList（S、G）に追加する必要があります。
InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) and UpstreamPorts(*,G).
InheritedUpstreamPorts（S、G）：これは、UpstreamPorts（S、G）とUpstreamPorts（*、G）の和集合です。
UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes TRUE, then this set is set to UpstreamPorts(*,G). Otherwise, this set is empty. UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to OutgoingPortList(S,G).
UpstreamPorts（S、G、rpt）：PruneDesired（S、G、rpt）がTRUEになると、このセットはUpstreamPorts（*、G）に設定されます。それ以外の場合、このセットは空です。 UpstreamPorts（*、G）（-）UpstreamPorts（S、G、rpt）をOutgoingPortList（S、G）に追加する必要があります。
UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and (*,G) Join/Prune messages MUST be sent to a subset of UpstreamPorts(G) as specified in Section 2.6.6.1.
UpstreamPorts（G）：このセットは、指定されたGのすべてのUpstreamPorts（S、G）およびUpstreamPorts（*、G）の和集合です。プロキシ（S、G）結合/プルーニングおよび（*、G）結合/プルーニングメッセージセクション2.6.6.1で指定されているように、UpstreamPorts（G）のサブセットに送信する必要があります。
PWPorts: This is the set of all PWs.
PWPorts：これはすべてのPWのセットです。
OutgoingPortList(*,G): This is the set of all ports to which traffic needs to be forwarded on a (*,G) match.
OutgoingPortList（*、G）：これは、（*、G）一致でトラフィックを転送する必要があるすべてのポートのセットです。
OutgoingPortList(S,G): This is the set of all ports to which traffic needs to be forwarded on an (S,G) match.
OutgoingPortList（S、G）：これは、（S、G）一致でトラフィックを転送する必要があるすべてのポートのセットです。
See Section 2.12 ("Data-Forwarding Rules") for the specification on how OutgoingPortList is calculated.
OutgoingPortListの計算方法の仕様については、セクション2.12（「データ転送ルール」）を参照してください。
NumETsActive(Port,*,G): This is the number of (Port,*,G,N) entries that have the Expiry Timer running. This macro keeps track of the number of Join(*,G)s that are received on this Port with different upstream neighbors.
NumETsActive（Port、*、G）：これは、有効期限タイマーが実行されている（Port、*、G、N）エントリの数です。このマクロは、アップストリームネイバーが異なるこのポートで受信したJoin（*、G）の数を追跡します。
NumETsActive(Port,S,G): This is the number of (Port,S,G,N) entries that have the Expiry Timer running. This macro keeps track of the number of Join(S,G)s that are received on this Port with different upstream neighbors.
NumETsActive（Port、S、G）：これは、有効期限タイマーが実行されている（Port、S、G、N）エントリの数です。このマクロは、アップストリームネイバーが異なるこのポートで受信したJoin（S、G）の数を追跡します。
JoinAttributeTlvs(*,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are TLVs that may be present in received Join(*,G) messages. An example would be Reverse Path Forwarding (RPF) Vectors (RFC 5496 [RPF-VECTOR]). If present, they must be copied to JoinAttributeTlvs(*,G).
JoinAttributeTlvs（*、G）：結合属性（RFC 5384 [JOIN-ATTR]）は、受信したJoin（*、G）メッセージに存在する可能性のあるTLVです。例は、Reverse Path Forwarding（RPF）ベクトル（RFC 5496 [RPF-VECTOR]）です。存在する場合は、JoinAttributeTlvs（*、G）にコピーする必要があります。
JoinAttributeTlvs(S,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are TLVs that may be present in received Join(S,G) messages. If present, they must be copied to JoinAttributeTlvs(S,G).
JoinAttributeTlvs（S、G）：結合属性（RFC 5384 [JOIN-ATTR]）は、受信したJoin（S、G）メッセージに存在する可能性のあるTLVです。存在する場合は、JoinAttributeTlvs（S、G）にコピーする必要があります。
Since there are a few differences between the downstream state machines of PIM-SM routers and PIM-SM snooping PEs, we specify the details of the downstream state machine of PIM-SM snooping PEs, at the risk of repeating most of the text documented in RFC 7761 [PIM-SM].
PIM-SMルータのダウンストリームステートマシンとPIM-SMスヌーピングPEの間にはいくつかの違いがあるため、PIM-SMスヌーピングPEのダウンストリームステートマシンの詳細を指定します。 RFC 7761 [PIM-SM]。
In PIM routing protocols, states are built per (S,G). On a router, an (S,G) has only one RPF-Neighbor. However, a PIM snooping PE does not have the Layer 3 routing information available to the routers in order to determine the RPF-Neighbor for a multicast flow. It merely discovers it by snooping the Join/Prune message. A PE could have snooped on two or more different Join/Prune messages for the same (S,G) that could have carried different Upstream Neighbor fields. This could happen during transient network conditions or due to dual-homed sources. A PE cannot make assumptions on which one to pick but instead must allow the CE routers to decide which upstream neighbor gets elected as the RPF-Neighbor. And for this purpose, the PE will have to track downstream and upstream Joins and Prunes per (S,G,N).
PIMルーティングプロトコルでは、状態は（S、G）ごとに作成されます。ルータでは、（S、G）にはRPFネイバーが1つだけあります。ただし、PIMスヌーピングPEには、マルチキャストフローのRPFネイバーを決定するために、ルータが利用できるレイヤ3ルーティング情報がありません。それは単にJoin / Pruneメッセージをスヌーピングすることによってそれを発見します。 PEは、異なる（S、G）に対する2つ以上の異なるJoin / Pruneメッセージをスヌーピングし、異なるアップストリームネイバーフィールドを運ぶ可能性があります。これは、一時的なネットワーク状態の間、またはデュアルホームのソースが原因で発生する可能性があります。 PEはどちらを選択するかを想定できませんが、代わりにCEルータがRPFネイバーとして選出されるアップストリームネイバーを決定できるようにする必要があります。そしてこの目的のために、PEは（S、G、N）ごとにダウンストリームとアップストリームの結合とプルーンを追跡する必要があります。
A Join(*,G) or Prune(*,G) is considered "received" if one of the following conditions is met:
Join（*、G）またはPrune（*、G）は、次のいずれかの条件が満たされた場合に「受信済み」と見なされます。
o The port on which it arrived is not Port(N) where N is the upstream neighbor N of the Join/Prune(*,G).
o それが到着したポートは、Port（N）ではありません。Nは、Join / Prune（*、G）のアップストリームネイバーNです。
o If both Port(N) and the arrival port are PWs, then there exists at least one other (*,G,Nx) or (Sx,G,Nx) state with an AC UpstreamPort.
o Port（N）と到着ポートの両方がPWの場合、AC UpstreamPortで少なくとも1つの他の（*、G、Nx）または（Sx、G、Nx）状態が存在します。
For simplicity, the case where both Port(N) and the arrival port are PWs is referred to as "PW-only Join/Prune" in this document. The PW-only Join/Prune handling is so that the Port(N) PW can be added to the related forwarding entries' OutgoingPortList to trigger an Assert, but that is only needed for those states with AC UpstreamPorts. Note that in the PW-only case, it is OK for the arrival port and Port(N) to be the same. See Appendix B for examples.
簡単にするために、Port（N）と到着ポートの両方がPWである場合を、このドキュメントでは「PWのみのJoin / Prune」と呼びます。 PWのみのJoin / Prune処理は、Port（N）PWを関連する転送エントリのOutgoingPortListに追加してアサートをトリガーできるようにするものですが、これはACアップストリームポートを使用する状態でのみ必要です。 PWのみの場合、到着ポートとPort（N）が同じであっても問題ないことに注意してください。例については、付録Bを参照してください。
When a router receives a Join(*,G) or a Prune(*,G) with upstream neighbor N, it must process the message as defined in the state machine below. Note that the macro computations of the various macros resulting from this state machine transition are exactly as specified in RFC 7761 [PIM-SM].
ルータは、上流ネイバーNでJoin（*、G）またはPrune（*、G）を受信すると、以下の状態マシンで定義されているようにメッセージを処理する必要があります。この状態マシンの遷移から生じるさまざまなマクロのマクロ計算は、RFC 7761 [PIM-SM]で指定されているとおりであることに注意してください。
We define the following per-port (*,G,N) macro to help with the state machine below.
以下のステートマシンに役立つように、次のポートごとの（*、G、N）マクロを定義します。
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(*,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | -> PP state |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) | PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
Figure 1: Downstream Per-Port (*,G) State Machine in Tabular Form
図1：表形式のダウンストリームのポートごと（*、G）のステートマシン
Action RxJoin(N):
アクションRxJoin（N）：
If ET(N) is not already running, then start ET(N). Otherwise, restart ET(N). If N is not already in UpstreamNeighbors(*,G), then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with upstream neighbor N to be forwarded upstream. If there are Join Attribute TLVs in the received (*,G) message and if they are different from the recorded JoinAttributeTlvs(*,G), then copy them into JoinAttributeTlvs(*,G). In the case of conflicting attributes, the PE will need to perform conflict resolution per (N) as described in RFC 5384 [JOIN-ATTR].
ET（N）がまだ実行されていない場合は、ET（N）を起動します。それ以外の場合は、ET（N）を再起動します。 NがまだUpstreamNeighbors（*、G）にない場合は、NをUpstreamNeighbors（*、G）に追加し、上流ネイバーNでJoin（*、G）をトリガーして上流に転送します。受信した（*、G）メッセージに結合属性TLVがあり、それらが記録されたJoinAttributeTlvs（*、G）と異なる場合は、JoinAttributeTlvs（*、G）にコピーします。属性が競合する場合、RFC 5384 [JOIN-ATTR]で説明されているように、PEは（N）ごとに競合解決を実行する必要があります。
Action PPTExpiry(N):
アクションPPTExpiry（N）：
Same as Action ETExpiry(N) below, plus send a Prune-Echo(*,G) with upstream neighbor N on the downstream port.
以下のアクションETExpiry（N）と同じですが、ダウンストリームポートでアップストリームネイバーNとともにPrune-Echo（*、G）を送信します。
Action ETExpiry(N):
アクションETExpiry（N）：
Disable timers ET(N) and PPT(N). Delete Neighbor state (Port,*,G,N). If there are no other (Port,*,G) states with NumETsActive(Port,*,G) > 0, transition DownstreamJPState (RFC 7761 [PIM-SM]) to NoInfo. If there are no other (Port,*,G,N) states (different ports but for the same N), remove N from UpstreamPorts(*,G) -- this will also trigger the Upstream Finite State Machine (FSM) with "JoinDesired(*,G,N) to FALSE".
タイマーET（N）およびPPT（N）を無効にします。ネイバー状態（ポート、*、G、N）を削除します。 NumETsActive（Port、*、G）> 0の他の（Port、*、G）状態がない場合は、DownstreamJPState（RFC 7761 [PIM-SM]）をNoInfoに移行します。他の（ポート、*、G、N）状態がない場合（異なるポートが同じNの場合）、UpstreamPorts（*、G）からNを削除します。これにより、「Upstream Finite State Machine（FSM）with " JoinDesired（*、G、N）をFALSEに」。
A Join(S,G) or Prune(S,G) is considered "received" if one of the following conditions is met:
Join（S、G）またはPrune（S、G）は、次のいずれかの条件が満たされた場合に「受信済み」と見なされます。
o The port on which it arrived is not Port(N) where N is the upstream neighbor N of the Join/Prune(S,G).
o それが到着したポートは、Port（N）ではありません。Nは、Join / Prune（S、G）のアップストリームネイバーNです。
o If both Port(N) and the arrival port are PWs, then there exists at least one other (*,G,Nx) or (S,G,Nx) state with an AC UpstreamPort.
o Port（N）と到着ポートの両方がPWである場合、AC UpstreamPortで少なくとも1つの他の（*、G、Nx）または（S、G、Nx）状態が存在します。
For simplicity, the case where both Port(N) and the arrival port are PWs is referred to as "PW-only Join/Prune" in this document. The PW-only Join/Prune handling is so that the Port(N) PW can be added to the related forwarding entries' OutgoingPortList to trigger an Assert, but that is only needed for those states with AC UpstreamPorts. Note that in the PW-only case, it is OK for the arrival port and Port(N) to be the same. See Appendix B for examples.
簡単にするために、Port（N）と到着ポートの両方がPWである場合を、このドキュメントでは「PWのみのJoin / Prune」と呼びます。 PWのみのJoin / Prune処理は、Port（N）PWを関連する転送エントリのOutgoingPortListに追加してアサートをトリガーできるようにするものですが、これはACアップストリームポートを使用する状態でのみ必要です。 PWのみの場合、到着ポートとPort（N）が同じであっても問題ないことに注意してください。例については、付録Bを参照してください。
When a router receives a Join(S,G) or a Prune(S,G) with upstream neighbor N, it must process the message as defined in the state machine below. Note that the macro computations of the various macros resulting from this state machine transition are exactly as specified in RFC 7761 [PIM-SM].
ルータは、上流ネイバーNでJoin（S、G）またはPrune（S、G）を受信すると、以下の状態マシンで定義されているようにメッセージを処理する必要があります。この状態マシンの遷移から生じるさまざまなマクロのマクロ計算は、RFC 7761 [PIM-SM]で指定されているとおりであることに注意してください。
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
Figure 2: Downstream Per-Port (S,G) State Machine in Tabular Form
図2：表形式のダウンストリームPer-Port（S、G）ステートマシン
Action RxJoin(N):
アクションRxJoin（N）：
If ET(N) is not already running, then start ET(N). Otherwise, restart ET(N).
ET（N）がまだ実行されていない場合は、ET（N）を起動します。それ以外の場合は、ET（N）を再起動します。
If N is not already in UpstreamNeighbors(S,G), then add N to UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream neighbor N to be forwarded upstream. If there are Join Attribute TLVs in the received (S,G) message and if they are different from the recorded JoinAttributeTlvs(S,G), then copy them into JoinAttributeTlvs(S,G). In cases of conflicting attributes, the PE will need to perform conflict resolution per (N) as described in RFC 5384 [JOIN-ATTR].
NがまだUpstreamNeighbors（S、G）にない場合は、NをUpstreamNeighbors（S、G）に追加し、上流ネイバーNでJoin（S、G）をトリガーして上流に転送します。受信した（S、G）メッセージに結合属性TLVがあり、それらが記録されたJoinAttributeTlvs（S、G）と異なる場合は、それらをJoinAttributeTlvs（S、G）にコピーします。属性が競合する場合、RFC 5384 [JOIN-ATTR]で説明されているように、PEは（N）ごとに競合解決を実行する必要があります。
Action PPTExpiry(N):
アクションPPTExpiry（N）：
Same as Action ETExpiry(N) below, plus send a Prune-Echo(S,G) with upstream neighbor N on the downstream port.
以下のアクションETExpiry（N）と同じです。さらに、ダウンストリームポートでアップストリームネイバーNを使用してPrune-Echo（S、G）を送信します。
Action ETExpiry(N):
アクションETExpiry（N）：
Disable timers ET(N) and PPT(N). Delete Neighbor state (Port,S,G,N). If there are no other (Port,S,G) states with NumETsActive(Port,S,G) > 0, transition DownstreamJPState to NoInfo. If there are no other (Port,S,G,N) states (different ports but for the same N), remove N from UpstreamPorts(S,G) -- this will also trigger the Upstream FSM with "JoinDesired(S,G,N) to FALSE".
タイマーET（N）およびPPT（N）を無効にします。ネイバー状態（ポート、S、G、N）を削除します。 NumETsActive（Port、S、G）> 0である他の（Port、S、G）状態がない場合、DownstreamJPStateをNoInfoに遷移します。他の（ポート、S、G、N）状態がない場合（異なるポートで同じNの場合）、UpstreamPorts（S、G）からNを削除します。これにより、 "JoinDesired（S、G 、N）からFALSEへ」。
A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on which it was received is not also the port on which the upstream neighbor N of the Join/Prune(S,G,rpt) was learned.
Join（S、G、rpt）またはPrune（S、G、rpt）は、受信されたポートが、Join / Prune（S、Gの上流ネイバーNが接続されているポートでもない場合に、「受信」されます。 、rpt）は学習されました。
While it is important to ensure that the (S,G) and (*,G) state machines allow for handling per-(S,G,N) states, it is not as important for (S,G,rpt) states. It suffices to say that the downstream (S,G,rpt) state machine is the same as what is defined in Section 4.5.3 of RFC 7761 [PIM-SM].
（S、G）および（*、G）ステートマシンが（S、G、N）状態ごとに処理できることを確認することが重要ですが、（S、G、rpt）状態ではそれほど重要ではありません。ダウンストリーム（S、G、rpt）ステートマシンは、RFC 7761 [PIM-SM]のセクション4.5.3で定義されているものと同じであると言えば十分です。
This section applies only to a PIM relay/proxying PE and not to a PIM snooping PE.
このセクションは、PIMリレー/プロキシPEにのみ適用され、PIMスヌーピングPEには適用されません。
A full PIM proxying (not relay) PE MUST implement the Upstream FSM along the lines of the procedure described in Section 4.5.4 of RFC 7761 [PIM-SM].
完全なPIMプロキシ（リレーではない）PEは、RFC 7761 [PIM-SM]のセクション4.5.4で説明されている手順に従ってアップストリームFSMを実装する必要があります。
For the purposes of the Upstream FSM, a Join or Prune message with upstream neighbor N is "seen" on a PIM relay/proxying PE if the port on which the message was received is also Port(N) and the port is an AC. The AC requirement is needed because a Join received on the Port(N) PW must not suppress this PE's Join on that PW.
アップストリームFSMの目的のために、メッセージが受信されたポートもPort（N）であり、ポートがACである場合、PIMリレー/プロキシPEでアップストリームネイバーNのJoinまたはPruneメッセージが「認識」されます。 Port（N）PWで受信された結合は、そのPWでのこのPEの結合を抑制してはならないため、AC要件が必要です。
A PIM relay PE does not implement the Upstream FSM. It simply forwards received Join/Prune messages out of the same set of upstream ports as in the PIM proxying case.
PIMリレーPEは、アップストリームFSMを実装していません。 PIMプロキシの場合と同じアップストリームポートのセットから、受信したJoin / Pruneメッセージを転送するだけです。
In order to correctly facilitate Asserts among the CE routers, such Join/Prune messages need to send not only towards the upstream neighbor but also on certain PWs, as described below.
CEルータ間のアサートを正しく促進するために、このようなJoin / Pruneメッセージは、以下に説明するように、上流のネイバーだけでなく特定のPWにも送信する必要があります。
If JoinAttributeTlvs(*,G) is not empty, then it must be encoded in a Join(*,G) message sent upstream.
JoinAttributeTlvs（*、G）が空でない場合は、上流に送信されるJoin（*、G）メッセージにエンコードする必要があります。
If JoinAttributeTlvs(S,G) is not empty, then it must be encoded in a Join(S,G) message sent upstream.
JoinAttributeTlvs（S、G）が空でない場合は、上流に送信されるJoin（S、G）メッセージにエンコードする必要があります。
The following rules apply to both (1) forwarded (in the case of PIM relay) and (2) refreshed and triggered (in the case of PIM proxying) (S,G) / (*,G) Join/Prune messages.
次のルールは、（1）転送（PIMリレーの場合）と（2）更新およびトリガー（PIMプロキシの場合）（S、G）/（*、G）Join / Pruneメッセージの両方に適用されます。
o The Upstream Neighbor field in the Join/Prune to be sent is set to the N in the corresponding Upstream FSM.
o 送信されるJoin / Pruneのアップストリームネイバーフィールドは、対応するアップストリームFSMのNに設定されます。
o If Port(N) is an AC, send the message to Port(N).
o Port（N）がACの場合、メッセージをPort（N）に送信します。
o Additionally, if OutgoingPortList(x,G,N) contains at least one AC, then the message MUST be sent to at least all the PWs in UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for (S,G)). Alternatively, the message MAY be sent to all PWs.
o さらに、OutgoingPortList（x、G、N）に少なくとも1つのACが含まれている場合、メッセージはUpstreamPorts（G）（for（*、G））またはInheritedUpstreamPorts（S、G）（ （S、G）の場合）。または、メッセージはすべてのPWに送信される場合があります。
Sending to a subset of PWs as described above guarantees that if traffic (of the same flow) from two upstream routers were to reach this PE, then the two routers will receive from each other, triggering an Assert.
上記のようにPWのサブセットに送信すると、2つの上流ルーターからの（同じフローの）トラフィックがこのPEに到達した場合、2つのルーターが互いに受信し、アサートがトリガーされます。
Sending to all PWs guarantees that if two upstream routers both send traffic for the same flow (even if it is to different sets of downstream PEs), then the two routers will receive from each other, triggering an Assert.
すべてのPWに送信すると、2つのアップストリームルータが両方とも同じフローのトラフィックを送信する場合（たとえそれがダウンストリームPEの異なるセットに送信されたとしても）、2つのルータが互いに受信し、アサートをトリガーすることが保証されます。
Bidirectional PIM (BIDIR-PIM) is a variation of PIM-SM. The main differences between PIM-SM and BIDIR-PIM are as follows:
双方向PIM（BIDIR-PIM）は、PIM-SMのバリエーションです。 PIM-SMとBIDIR-PIMの主な違いは次のとおりです。
o There are no source-based trees, and SSM is not supported (i.e., no (S,G) states) in BIDIR-PIM.
o ソースベースのツリーはなく、BIDIR-PIMではSSMはサポートされていません（つまり、（S、G）状態はありません）。
o Multicast traffic can flow up the shared tree in BIDIR-PIM.
o マルチキャストトラフィックは、BIDIR-PIMの共有ツリーを上に流れることができます。
o To avoid forwarding loops, one router on each link is elected as the Designated Forwarder (DF) for each RP in BIDIR-PIM.
o 転送ループを回避するために、BIDIR-PIMの各RPの指定フォワーダー（DF）として、各リンク上の1つのルーターが選出されます。
The main advantage of BIDIR-PIM is that it scales well for many-to-many applications. However, the lack of source-based trees means that multicast traffic is forced to remain on the shared tree.
BIDIR-PIMの主な利点は、多対多のアプリケーションに合わせて拡張できることです。ただし、ソースベースのツリーがないことは、マルチキャストトラフィックが共有ツリーに留まることを余儀なくされることを意味します。
As described in RFC 5015 [BIDIR-PIM], parts of a BIDIR-PIM-enabled network may forward traffic without exchanging Join/Prune messages -- for instance, between DFs and the Rendezvous Point Link (RPL).
RFC 5015 [BIDIR-PIM]で説明されているように、BIDIR-PIM対応ネットワークの一部は、たとえばDFとRendezvous Point Link（RPL）の間で、Join / Pruneメッセージを交換せずにトラフィックを転送できます。
As the described procedures for PIM snooping rely on the presence of Join/Prune messages, enabling PIM snooping on BIDIR-PIM networks could break the BIDIR-PIM functionality. Deploying PIM snooping on BIDIR-PIM-enabled networks will require some further study. Some thoughts on this topic are discussed in Appendix A.
説明されているPIMスヌーピングの手順は、Join / Pruneメッセージの存在に依存しているため、BIDIR-PIMネットワークでPIMスヌーピングを有効にすると、BIDIR-PIM機能が破損する可能性があります。 BIDIR-PIM対応ネットワークにPIMスヌーピングを導入するには、さらに調査が必要です。このトピックに関するいくつかの考えは、付録Aで説明されています。
Whenever IGMP snooping is enabled in conjunction with PIM snooping in the same VPLS instance, the PE SHOULD follow these rules:
IGMPスヌーピングが同じVPLSインスタンスでPIMスヌーピングとともに有効になっている場合は常に、PEは次のルールに従う必要があります。
o To maintain the list of multicast routers and ports on which they are attached, the PE SHOULD NOT use the rules described in RFC 4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered by PIM snooping. This list SHOULD then be used to apply the first forwarding rule (rule 1) listed in Section 2.1.1 of RFC 4541 [IGMP-SNOOP].
o マルチキャストルーターとそれらが接続されているポートのリストを維持するために、PEはRFC 4541 [IGMP-SNOOP]で説明されているルールを使用してはなりません（SHOULD NOT）が、PIMスヌーピングによって検出されたネイバーに依存する必要があります（SHOULD）。次に、このリストを使用して、RFC 4541 [IGMP-SNOOP]のセクション2.1.1に記載されている最初の転送ルール（ルール1）を適用する必要があります（SHOULD）。
o If the PE supports proxy reporting, an IGMP membership learned only on a port to which a PIM neighbor is attached (i.e., not learned elsewhere) SHOULD NOT be included in the summarized upstream report sent to that port.
o PEがプロキシレポートをサポートする場合、IGMPメンバーシップは、PIMネイバーが接続されているポートでのみ学習されます（他の場所では学習されません）。そのポートに送信される要約アップストリームレポートには含めないでください。
The key characteristic of PIM-DM is flood-and-prune behavior. Shortest-path trees are built as a multicast source starts transmitting.
PIM-DMの主な特徴は、フラッドアンドプルーン動作です。マルチキャストソースが送信を開始すると、最短パスツリーが構築されます。
PIM-DM states are built by snooping on the PIM-DM Join, Prune, Graft, and State Refresh messages received on ACs/PWs and State Refresh messages sent on ACs/PWs. By snooping on these PIM-DM messages, a PE builds the following states per (S,G,N) where S is the address of the multicast source, G is the group address, and N is the upstream neighbor to which Prunes/Grafts are sent by downstream CEs:
PIM-DMの状態は、AC / PWで受信されたPIM-DMのJoin、Prune、Graft、およびState Refreshメッセージと、AC / PWで送信されたState Refreshメッセージをスヌーピングすることによって構築されます。これらのPIM-DMメッセージをスヌーピングすることにより、PEは（S、G、N）に従って次の状態を構築します。ここで、Sはマルチキャストソースのアドレス、Gはグループアドレス、Nはプルーニング/グラフトの上流のネイバーです。ダウンストリームCEによって送信されます。
Per PIM(S,G,N):
ぺｒ ぴＭ（Ｓ、Ｇ、ん）：
Port PIM(S,G,N) Prune State:
ポートPIM（S、G、N）プルーン状態：
* DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" (P), "Prune-Pending" (PP)}
* DownstreamPState（S、G、N、Port）：{"NoInfo"（NI）、 "Pruned"（P）、 "Prune-Pending"（PP）}のいずれか
* Prune-Pending Timer (PPT)
* プルーンペンディングタイマー（PPT）
* Prune Timer (PT)
* プルーンタイマー（PT）
* Upstream Port (valid if the PIM(S,G,N) Prune state is "Pruned")
* アップストリームポート（PIM（S、G、N）プルーニングステートが「プルーニング」の場合に有効）
The downstream per-port PIM(S,G,N) state machine is as defined in Section 4.4.2 of RFC 3973 [PIM-DM], with a few changes relevant to PIM snooping. When reading Section 4.4.2 of RFC 3973 [PIM-DM], please be aware that, for the purposes of PIM snooping, the downstream states are built per (S,G,N,Downstream-Port) in PIM snooping and not per (Downstream-Interface,S,G) as in a PIM-DM router. As noted in Section 2.9.1, the states (DownstreamPState) and timers (PPT and PT) are per (S,G,N,Port).
ダウンストリームのポートごとのPIM（S、G、N）ステートマシンは、RFC 3973 [PIM-DM]のセクション4.4.2で定義されていますが、PIMスヌーピングに関連するいくつかの変更があります。 RFC 3973 [PIM-DM]のセクション4.4.2を読む場合、PIMスヌーピングの目的で、ダウンストリーム状態はPIMスヌーピングではなく（S、G、N、Downstream-Port）ごとに構築されることに注意してください（ダウンストリームインターフェイス、S、G）PIM-DMルーターと同様。セクション2.9.1で述べたように、状態（DownstreamPState）とタイマー（PPTおよびPT）は（S、G、N、Port）ごとです。
Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all routers unless explicitly pruned. Since PIM-DM routers do not prune on non-RPF interfaces, PEs should typically not receive Prunes on Port(RPF-Neighbor). So, the asserting routers should typically be in pim_oiflist(S,G). In most cases, Assert election should occur naturally without any special handling, since data traffic will be forwarded to the asserting routers.
PIM-DMはフラッドアンドプルーンプロトコルであるため、明示的にプルーニングされない限り、トラフィックはすべてのルータにフラッディングされます。 PIM-DMルーターは非RPFインターフェイスでプルーニングしないため、PEは通常、ポート（RPF-Neighbor）でプルーンを受信するべきではありません。したがって、アサーティングルーターは通常、pim_oiflist（S、G）にある必要があります。データトラフィックはアサーティングルーターに転送されるため、ほとんどの場合、アサート選択は特別な処理なしで自然に行われるはずです。
However, there are some scenarios where a Prune might be received on a port that is also an upstream port. If we prune the port from pim_oiflist(S,G), then it would not be possible for the asserting routers to determine if traffic arrived on their downstream port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that data traffic flows to the upstream ports.
ただし、プルーンがアップストリームポートでもあるポートで受信される可能性があるいくつかのシナリオがあります。 pim_oiflist（S、G）からポートをプルーニングする場合、アサーティングルーターがトラフィックがダウンストリームポートに到着したかどうかを判断することはできません。これは、データトラフィックがアップストリームポートに流れるようにpim_iifs（S、G）をpim_oiflist（S、G）に追加することで修正できます。
As noted earlier, PIM snooping will work correctly only if Join suppression is disabled in the VPLS. If Join suppression is enabled in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast to work correctly. This section applies specifically to full proxying and not to relay.
前述のように、VPLSで参加抑制が無効になっている場合にのみ、PIMスヌーピングが正しく機能します。 VPLSで参加抑制が有効になっている場合、VPLSマルチキャストが正しく機能するために、PEはPIMリレー/プロキシを実行する必要があります。このセクションは、リレーではなく、完全プロキシに特に適用されます。
A PIM proxying PE consumes Join/Prune messages and regenerates PIM Join/Prune messages to be sent upstream by implementing the Upstream FSM as specified in Section 4.5.4 of RFC 7761 [PIM-SM]. This is the only difference from PIM relay.
PIMプロキシPEは、Join / Pruneメッセージを消費し、RFC 7761 [PIM-SM]のセクション4.5.4で指定されているアップストリームFSMを実装することにより、アップストリームに送信されるPIM Join / Pruneメッセージを再生成します。これがPIMリレーとの唯一の違いです。
The source IP address in PIM packets sent upstream SHOULD be the address of a PIM downstream neighbor in the corresponding Join/Prune state. The chosen address MUST NOT be the Upstream Neighbor field to be encoded in the packet. The Layer 2 encapsulation for the selected source IP address MUST be the encapsulation recorded in the PIM Neighbor Database for that IP address.
アップストリームに送信されたPIMパケットのソースIPアドレスは、対応するJoin / Prune状態のPIMダウンストリームネイバーのアドレスである必要があります（SHOULD）。選択したアドレスは、パケットにエンコードされるアップストリームネイバーフィールドであってはなりません。選択した送信元IPアドレスのレイヤ2カプセル化は、そのIPアドレスのPIMネイバーデータベースに記録されているカプセル化でなければなりません。
PIM snooping/relay/proxying could be enabled on a LAN that connects a multicast source and a PIM First-Hop Router (FHR). As the FHR will not send any downstream Join/Prune messages, we will not be able to establish any forwarding states for that source. Therefore, if there is a source in the CE network that connects directly into the VPLS instance, then multicast traffic from that source MUST be sent to all PIM routers on the VPLS instance in addition to the IGMP receivers in the VPLS. If there is already (S,G) or (*,G) snooping state that is formed on any PE, this will not happen per the current forwarding rules and guidelines. So, in order to determine if traffic needs to be flooded to all routers, a PE must be able to determine if the traffic came from a host on that LAN. There are three ways to address this problem:
PIMスヌーピング/リレー/プロキシは、マルチキャストソースとPIMファーストホップルーター（FHR）を接続するLANで有効にできます。 FHRはダウンストリームのJoin / Pruneメッセージを送信しないため、そのソースの転送状態を確立できません。したがって、VPLSインスタンスに直接接続するソースがCEネットワークにある場合、そのソースからのマルチキャストトラフィックは、VPLSのIGMPレシーバーに加えて、VPLSインスタンスのすべてのPIMルーターに送信される必要があります。 PEで（S、G）または（*、G）スヌーピング状態がすでに形成されている場合、これは現在の転送ルールとガイドラインに従って発生しません。したがって、トラフィックをすべてのルーターにフラッディングする必要があるかどうかを判断するために、PEは、トラフィックがそのLAN上のホストからのものかどうかを判断できる必要があります。この問題に対処するには3つの方法があります。
o The PE would have to do IPv4 ARP snooping and/or IPv6 Neighbor Discovery snooping to determine if a source is directly connected.
o PEは、ソースが直接接続されているかどうかを判断するために、IPv4 ARPスヌーピングやIPv6ネイバー探索スヌーピングを行う必要があります。
o Another option is to configure all PEs to indicate that there are CE sources that are directly connected to the VPLS instance and disallow snooping for the groups for which the source is going to send traffic. This way, traffic from that source to those groups will always be flooded within the provider network.
o 別のオプションは、VPLSインスタンスに直接接続されているCEソースがあり、ソースがトラフィックを送信するグループのスヌーピングを許可しないことを示すようにすべてのPEを構成することです。このようにして、そのソースからそれらのグループへのトラフィックは、常にプロバイダーネットワーク内でフラッディングされます。
o A third option is to require that sources of CE multicast traffic must be behind a router.
o 3番目のオプションは、CEマルチキャストトラフィックのソースがルーターの背後にあることを要求することです。
This document recommends the third option -- sources of traffic must be behind a router.
このドキュメントでは、3番目のオプションを推奨しています。トラフィックのソースはルーターの背後にある必要があります。
First, we define the rules that are common to PIM-SM and PIM-DM PEs. Forwarding rules for each protocol type are specified in the subsections below.
まず、PIM-SMおよびPIM-DM PEに共通のルールを定義します。各プロトコルタイプの転送ルールは、以下のサブセクションで指定されています。
If there is no matching forwarding state, then the PE SHOULD discard the packet, i.e., the UserDefinedPortList (Sections 2.12.1 and 2.12.2) SHOULD be empty.
一致する転送状態がない場合、PEはパケットを破棄する必要があります。つまり、UserDefinedPortList（セクション2.12.1および2.12.2）は空である必要があります（SHOULD）。
The following general rules MUST be followed when forwarding multicast traffic in a VPLS:
VPLSでマルチキャストトラフィックを転送するときは、次の一般的なルールに従う必要があります。
o Traffic arriving on a port MUST NOT be forwarded back onto the same port.
o ポートに到着するトラフィックは、同じポートに転送してはなりません。
o Due to VPLS split-horizon rules, traffic ingressing on a PW MUST NOT be forwarded to any other PW.
o VPLSスプリットホライズンルールにより、PWに進入するトラフィックを他のPWに転送してはなりません。
Per the rules in RFC 7761 [PIM-SM] and per the additional rules specified in this document,
RFC 7761 [PIM-SM]のルールおよびこのドキュメントで指定されている追加のルールに従って、
OutgoingPortList(*,G) = immediate_olist(*,G) (+)
UpstreamPorts(*,G) (+)
Port(PimDR)
OutgoingPortList(S,G) = inherited_olist(S,G) (+)
UpstreamPorts(S,G) (+)
(UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt)) (+)
Port(PimDR)
RFC 7761 [PIM-SM] specifies how immediate_olist(*,G) and inherited_olist(S,G) are built. PimDR is the IP address of the PIM DR in the VPLS.
RFC 7761 [PIM-SM]は、immediate_olist（*、G）およびinherited_olist（S、G）の構築方法を指定しています。 PimDRは、VPLS内のPIM DRのIPアドレスです。
The PIM-SM snooping data-forwarding rules are defined below in pseudocode:
PIM-SMスヌーピングデータ転送ルールは、以下の疑似コードで定義されています。
BEGIN iif is the incoming port of the multicast packet. S is the source IP address of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iifは、マルチキャストパケットの着信ポートです。 Sは、マルチキャストパケットの送信元IPアドレスです。 Gは、マルチキャストパケットの宛先IPアドレスです。
If there is (S,G) state on the PE Then OutgoingPortList = OutgoingPortList(S,G) Else if there is (*,G) state on the PE Then OutgoingPortList = OutgoingPortList(*,G) Else OutgoingPortList = UserDefinedPortList Endif
PEに（S、G）状態がある場合は、OutgoingPortList = OutgoingPortList（S、G）になり、そうでなければ、PEに（*、G）状態がある場合は、OutgoingPortList = OutgoingPortList（*、G）になり、OutgoingPortList = UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
iifがACの場合、OutgoingPortList = OutgoingPortList（-）iif Else ## iifがPW OutgoingPortList = OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END First, if there is (S,G) state on the PE, then the set of outgoing ports is OutgoingPortList(S,G).
パケットをOutgoingPortListに転送します。 END最初に、PEに（S、G）状態がある場合、送信ポートのセットはOutgoingPortList（S、G）です。
Otherwise, if there is (*,G) state on the PE, then the set of outgoing ports is OutgoingPortList(*,G).
それ以外で、PEに（*、G）状態がある場合、送信ポートのセットはOutgoingPortList（*、G）です。
The packet is forwarded to the selected set of outgoing ports while observing the general rules above in Section 2.12.
パケットは、上記のセクション2.12の一般的な規則に従って、選択された発信ポートのセットに転送されます。
The PIM-DM snooping data-forwarding rules are defined below in pseudocode:
PIM-DMスヌーピングデータ転送ルールは、以下の疑似コードで定義されています。
BEGIN iif is the incoming port of the multicast packet. S is the source IP address of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iifは、マルチキャストパケットの着信ポートです。 Sは、マルチキャストパケットの送信元IPアドレスです。 Gは、マルチキャストパケットの宛先IPアドレスです。
If there is (S,G) state on the PE Then OutgoingPortList = olist(S,G) Else OutgoingPortList = UserDefinedPortList Endif
PEに（S、G）状態がある場合、送信ポートリスト= olist（S、G）以外の送信ポートリスト= UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
iifがACの場合、OutgoingPortList = OutgoingPortList（-）iif Else ## iifがPW OutgoingPortList = OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END
パケットをOutgoingPortListに転送します。終わり
If there is forwarding state for (S,G), then forward the packet to olist(S,G) while observing the general rules above in Section 2.12.
（S、G）の転送状態がある場合は、上記の2.12項の一般的な規則に従って、パケットをolist（S、G）に転送します。
RFC 3973 [PIM-DM] specifies how olist(S,G) is constructed.
RFC 3973 [PIM-DM]は、olist（S、G）の構築方法を指定しています。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Security considerations provided in the VPLS solution documents (i.e., RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) apply to this document as well.
VPLSソリューションドキュメント（つまり、RFC 4762 [VPLS-LDP]およびRFC 4761 [VPLS-BGP]）で提供されるセキュリティの考慮事項は、このドキュメントにも適用されます。
[BIDIR-PIM] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <https://www.rfc-editor.org/info/rfc5015>.
[BIDIR-PIM] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<https ：//www.rfc-editor.org/info/rfc5015>。
[JOIN-ATTR] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, <https://www.rfc-editor.org/info/rfc5384>.
[JOIN-ATTR] Boers、A.、Wijnands、I。、およびE. Rosen、「Protocol Independent Multicast（PIM）Join Attribute Format」、RFC 5384、DOI 10.17487 / RFC5384、2008年11月、<https：// www .rfc-editor.org / info / rfc5384>。
[PIM-DM] 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>.
[PIM-DM] Adams、A.、Nicholas、J。、およびW. Siadak、「Protocol Independent Multicast-Dense Mode（PIM-DM）：Protocol Specification（Revised）」、RFC 3973、DOI 10.17487 / RFC3973、2005年1月、<https://www.rfc-editor.org/info/rfc3973>。
[PIM-SM] 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>.
[PIM-SM] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「プロトコルに依存しないマルチキャスト-スパースモード（PIM- SM）：Protocol Specification（Revised）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https://www.rfc-editor.org/info/rfc7761>。
[PIM-SSM] 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>.
[PIM-SSM] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<https://www.rfc-editor.org/info/rfc4607 >。
[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>。
[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>。
[RPF-VECTOR] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <https://www.rfc-editor.org/info/rfc5496>.
[RPF-VECTOR] Wijnands、IJ。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、DOI 10.17487 / RFC5496、2009年3月、<https：// www。 rfc-editor.org/info/rfc5496>。
[IGMP-SNOOP] 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>.
[IGMP-SNOOP] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、DOI 10.17487 / RFC4541、5月2006、<https://www.rfc-editor.org/info/rfc4541>。
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[VPLS-BGP] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service（VPLS）Using BGP for Auto-Discovery and Signaling"、RFC 4761、DOI 10.17487 / RFC4761、2007年1月<https://www.rfc-editor.org/info/rfc4761>。
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[VPLS-LDP] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、 <https://www.rfc-editor.org/info/rfc4762>。
[VPLS-MCAST] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <https://www.rfc-editor.org/info/rfc7117>.
[VPLS-MCAST] Aggarwal、R.、Ed。、Kamite、Y.、Fang、L.、Rekhter、Y.、and C. Kodeboniya、 "Multicast in Virtual Private LAN Service（VPLS）"、RFC 7117、DOI 10.17487 / RFC7117、2014年2月、<https://www.rfc-editor.org/info/rfc7117>。
[VPLS-MCAST-REQ] Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, DOI 10.17487/RFC5501, March 2009, <https://www.rfc-editor.org/info/rfc5501>.
[VPLS-MCAST-REQ] Kamite、Y.、Ed。、Wada、Y.、Serbest、Y.、Morin、T。、およびL. Fang、「仮想プライベートLANサービスでのマルチキャストサポートの要件」、RFC 5501、 DOI 10.17487 / RFC5501、2009年3月、<https://www.rfc-editor.org/info/rfc5501>。
This appendix describes some guidelines that may be used to preserve BIDIR-PIM functionality in combination with PIM snooping.
この付録では、BIDIR-PIM機能をPIMスヌーピングと組み合わせて維持するために使用できるいくつかのガイドラインについて説明します。
In order to preserve BIDIR-PIM snooping, routers need to set up forwarding states so that:
BIDIR-PIMスヌーピングを維持するために、ルーターは次のように転送状態を設定する必要があります。
o on the RPL, all traffic is forwarded to all Port(N) ports.
o RPLでは、すべてのトラフィックがすべてのPort（N）ポートに転送されます。
o on any other interface, traffic is always forwarded to the DF.
o 他のインターフェイスでは、トラフィックは常にDFに転送されます。
The information needed to set up these states may be obtained by:
これらの状態を設定するために必要な情報は、次の方法で取得できます。
o determining the mapping between the group (range) and the RP.
o グループ（範囲）とRP間のマッピングを決定します。
o snooping and storing DF election information.
o スヌーピングとDF選挙情報の保存。
o determining where the RPL is. This could be achieved by static configuration or by combining the information mentioned in the two bullet items above.
o RPLがどこにあるかを決定します。これは、静的構成によって、または上記の2つの箇条書き項目に記載されている情報を組み合わせることによって実現できます。
The BIDIR-PIM snooping data-forwarding rules are defined below in pseudocode:
BIDIR-PIMスヌーピングデータ転送ルールは、以下の疑似コードで定義されています。
BEGIN iif is the incoming port of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iifは、マルチキャストパケットの着信ポートです。 Gは、マルチキャストパケットの宛先IPアドレスです。
If there is forwarding state for G Then OutgoingPortList = olist(G) Else OutgoingPortList = UserDefinedPortList Endif
Gの転送状態がある場合OutgoingPortList = olist（G）Else OutgoingPortList = UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
iifがACの場合、OutgoingPortList = OutgoingPortList（-）iif Else ## iifがPW OutgoingPortList = OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END If there is forwarding state for G, then forward the packet to olist(G) while observing the general rules above in Section 2.12.
パケットをOutgoingPortListに転送します。 END Gの転送状態がある場合は、上記の2.12項の一般的な規則に従って、パケットをolist（G）に転送します。
RFC 5015 [BIDIR-PIM] specifies how olist(G) is constructed.
RFC 5015 [BIDIR-PIM]は、olist（G）の構築方法を指定しています。
Let us consider the scenario in Figure 3.
図3のシナリオを考えてみましょう。
+------+ AC3 +------+
| PE2 |-----| CE3 |
/| | +------+
/ +------+ |
/ | |
/ | |
/PW12 | |
/ | /---\
/ |PW23 | S |
/ | \---/
/ | |
/ | |
/ | |
+------+ / +------+ |
+------+ | PE1 |/ PW13 | PE3 | +------+
| CE1 |-----| |-------------| |-----| CE4 |
+------+ AC1 +------+ +------+ AC4 +------+
|
|AC2
+------+
| CE2 |
+------+
Figure 3: An Example Network for Triggering an Assert
図3：アサートをトリガーするためのネットワークの例
In the examples below, JT(Port,S,G,N) is the downstream Join Expiry Timer on the specified Port for the (S,G) with upstream neighbor N.
次の例では、JT（Port、S、G、N）は、（S、G）の指定されたポートのダウンストリーム加入期限タイマーであり、上流ネイバーはNです。
In the network depicted in Figure 3, S is the source of a multicast stream (S,G). CE1 and CE2 both have two ECMP routes to reach the source.
図3に示すネットワークでは、Sはマルチキャストストリーム（S、G）のソースです。 CE1とCE2の両方に、ソースに到達するための2つのECMPルートがあります。
1. CE1 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE3.
1. CE1は、UpstreamNeighbors（S、G）= CE3でJoin（S、G）を送信します。
2. PE1 snoops on the Join(S,G) and builds forwarding state, since it is received on an AC. It also floods the Join(S,G) in the VPLS. PE2 snoops on the Join(S,G) and builds forwarding state, since the Join(S,G)is targeting a neighbor residing on an AC. PE3 does not create forwarding state for (S,G) because this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G). Both PE2 and PE3 will also flood the Join(S,G) in the VPLS.
2. PE1はACで受信されるため、Join（S、G）をスヌーピングし、転送状態を構築します。また、VPLSのJoin（S、G）をフラッディングします。 Join（S、G）はACに存在するネイバーをターゲットにしているため、PE2はJoin（S、G）をスヌーピングし、転送状態を構築します。これはPWのみの結合であり、UpstreamPorts（*、G）にACを持つ既存の（*、G）状態も、既存の（S、G）もないため、PE3は（S、G）の転送状態を作成しません。 UpstreamPorts（S、G）にACがある状態。 PE2とPE3はどちらも、VPLSのJoin（S、G）をフラッディングします。
The resulting states at the PEs are as follows:
PEでの結果の状態は次のとおりです。
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states: No (S,G) state
PE3状態：いいえ（S、G）状態
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
3. マルチキャストストリーム（S、G）は、CE3-> PE2-> PE1-> CE1に沿って流れます。
4. Now CE2 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE4.
4. ここで、CE2は、UpstreamNeighbors（S、G）= CE4でJoin（S、G）を送信します。
5. All PEs snoop on the Join(S,G), build forwarding state, and flood the Join(S,G) in the VPLS. Note that for PE2, even though this is a PW-only Join, forwarding state is built on this Join(S,G), since PE2 has an existing (S,G) state with an AC in UpstreamPorts(S,G).
5. すべてのPEは、Join（S、G）をスヌープし、転送状態を構築し、VPLSのJoin（S、G）をフラッディングします。 PE2の場合、これはPWのみの結合ですが、PE2はUpstreamPorts（S、G）にACがある既存の（S、G）状態であるため、このJoin（S、G）で転送状態が構築されることに注意してください。
The resulting states at the PEs are as follows:
PEでの結果の状態は次のとおりです。
PE1 states:
JT(AC1,S,G,CE3) = active
JT(AC2,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 }
PE2 states:
JT(PW12,S,G,CE4) = JP_HoldTime
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
PE3 states:
JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 }
OutgoingPortList(S,G) = { PW13, AC4 }
6. The multicast stream (S,G) flows into the VPLS from two of the CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to PW23, and PE3 forwards the stream to AC4. This helps the CE routers to trigger Assert election. Let us say that CE3 becomes the Assert winner.
6. マルチキャストストリーム（S、G）は、CEの2つであるCE3とCE4からVPLSに流れ込みます。 PE2はCE3から受信したストリームをPW23に転送し、PE3はストリームをAC4に転送します。これは、CEルーターがアサート選択をトリガーするのに役立ちます。 CE3がAssertの勝者になるとしましょう。
7. CE3 sends an Assert message to the VPLS. The PEs flood the Assert message without examining it.
7. CE3はAssertメッセージをVPLSに送信します。 PEは検査せずにアサートメッセージをフラッディングします。
8. CE4 stops sending the multicast stream to the VPLS.
8. CE4は、VPLSへのマルチキャストストリームの送信を停止します。
9. CE2 notices an RPF change due to the Assert and sends a Prune(S,G) with upstream neighbor = CE4. CE2 also sends a Join(S,G) with upstream neighbor = CE3.
9. CE2は、アサートによるRPFの変更を認識し、上流のネイバー= CE4でPrune（S、G）を送信します。 CE2は、アップストリームネイバー= CE3のJoin（S、G）も送信します。
10. All the PEs start a Prune-Pending timer on the ports on which they received the Prune(S,G). When the Prune-Pending timer expires, all PEs will remove the downstream (S,G,CE4) states.
10. すべてのPEは、Prune（S、G）を受信したポートでPrune-Pendingタイマーを開始します。 Prune-Pendingタイマーの期限が切れると、すべてのPEがダウンストリーム（S、G、CE4）状態を削除します。
The resulting states at the PEs are as follows:
PEでの結果の状態は次のとおりです。
PE1 states:
JT(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, AC2, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states:
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW13, PW23 }
Note that at this point at PE3, since there is no AC in OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in UpstreamPorts(*,G) or UpstreamPorts(S,G), respectively, the existing (S,G) state at PE3 can also be removed. So, finally:
この時点ではPE3にあることに注意してください。OutgoingPortList（S、G）にACがなく、UpstreamPorts（*、G）またはUpstreamPorts（S、G）にACがある（*、G）または（S、G）状態がないためです。 ）、PE3の既存の（S、G）状態もそれぞれ削除できます。それで、最後に：
PE3 states: No (S,G) state
PE3状態：いいえ（S、G）状態
Note that at the end of the Assert election, there should be no duplicate traffic forwarded downstream, and traffic should flow only on the desired path. Also note that there are no unnecessary (S,G) states on PE3 after the Assert election.
アサート選出の終わりには、ダウンストリームに転送される重複トラフィックはなく、トラフィックは目的のパスのみに流れる必要があることに注意してください。また、アサート選出後のPE3には不要な（S、G）状態がないことに注意してください。
In the same network, let us assume that CE4 is the upstream neighbor towards the RP for G.
同じネットワークで、CE4がGのRPに向かうアップストリームネイバーであると仮定します。
JPST(S,G,N) is the JP sending timer for the (S,G) with upstream neighbor N.
JPST（S、G、N）は、アップストリームネイバーNを持つ（S、G）のJP送信タイマーです。
1. CE1 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE3.
1. CE1は、UpstreamNeighbors（S、G）= CE3でJoin（S、G）を送信します。
2. PE1 consumes the Join(S,G) and builds forwarding state, since the Join(S,G) is received on an AC.
2. Join（S、G）はACで受信されるため、PE1はJoin（S、G）を消費し、転送状態を構築します。
PE2 consumes the Join(S,G) and builds forwarding state, since the Join(S,G) is targeting a neighbor residing on an AC.
Join（S、G）はACに存在するネイバーをターゲットにしているため、PE2はJoin（S、G）を消費し、転送状態を構築します。
PE3 consumes the Join(S,G) but does not create forwarding state for (S,G), since this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G).
PE3はJoin（S、G）を消費しますが、（S、G）の転送状態を作成しません。これはPWのみの結合であり、UpstreamPorts（*、 G）UpstreamPorts（S、G）にACがある既存の（S、G）状態。
The resulting states at the PEs are as follows:
PEでの結果の状態は次のとおりです。
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states: No (S,G) state
PE3状態：いいえ（S、G）状態
Joins are triggered as follows: PE1 triggers a Join(S,G) targeting CE3. Since the Join(S,G) was received on an AC and is targeting a neighbor that is residing across a PW, the triggered Join(S,G) is sent on all PWs.
結合は次のようにトリガーされます。PE1は、CE3をターゲットとするJoin（S、G）をトリガーします。 Join（S、G）はACで受信され、PW全体に存在するネイバーをターゲットにしているため、トリガーされたJoin（S、G）はすべてのPWで送信されます。
PE2 triggers a Join(S,G) targeting CE3. Since the Join(S,G) is targeting a neighbor residing on an AC, it only sends the Join on AC3.
PE2は、CE3をターゲットとするJoin（S、G）をトリガーします。 Join（S、G）はACに常駐するネイバーをターゲットにしているため、AC3にのみJoinを送信します。
PE3 ignores the Join(S,G), since this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G).
これはPWのみの結合であり、UpstreamPorts（*、G）にACがある既存の（*、G）状態も、既存の（S、G）状態もないため、PE3はJoin（S、G）を無視します。 UpstreamPorts（S、G）のAC。
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
3. マルチキャストストリーム（S、G）は、CE3-> PE2-> PE1-> CE1に沿って流れます。
4. Now let us say that CE2 sends a Join(*,G) with UpstreamNeighbors(*,G) = CE4.
4. ここで、CE2が、UpstreamNeighbors（*、G）= CE4であるJoin（*、G）を送信するとします。
5. PE1 consumes the Join(*,G) and builds forwarding state, since the Join(*,G) is received on an AC.
5. PEは、Join（*、G）がACで受信されるため、Join（*、G）を消費し、転送状態を構築します。
PE2 consumes the Join(*,G); although this is a PW-only Join, forwarding state is built on this Join(*,G), since PE2 has an existing (S,G) state with an AC in UpstreamPorts(S,G). However, since this is a PW-only Join, PE2 only adds the PW towards PE3 (PW23) into UpstreamPorts(*,G) and hence into OutgoingPortList(*,G). It does not add the PW towards PE1 (PW12) into OutgoingPortList(*,G).
PE2はJoin（*、G）を使用します。これはPWのみのJoinですが、PE2はUpstreamPorts（S、G）にACを持つ既存の（S、G）状態を持っているため、転送状態はこのJoin（*、G）に基づいて構築されます。ただし、これはPWのみの結合であるため、PE2はPWをPE3（PW23）に向けてUpstreamPorts（*、G）に、したがってOutgoingPortList（*、G）に追加するだけです。 PE1（PW12）へのPWをOutgoingPortList（*、G）に追加しません。
PE3 consumes the Join(*,G) and builds forwarding state, since the Join(*,G) is targeting a neighbor residing on an AC.
Join（*、G）はACに存在するネイバーをターゲットにしているため、PE3はJoin（*、G）を消費し、転送状態を構築します。
The resulting states at the PEs are as follows:
PEでの結果の状態は次のとおりです。
PE1 states:
JT(AC1,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, PW13 }
PE2 states:
JT(PW12,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
PE3 states:
JT(PW13,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
Joins are triggered as follows: PE1 triggers a Join(*,G) targeting CE4. Since the Join(*,G) was received on an AC and is targeting a neighbor that is residing across a PW, the triggered Join(S,G) is sent on all PWs.
結合は次のようにトリガーされます。PE1は、CE4をターゲットとするJoin（*、G）をトリガーします。 Join（*、G）はACで受信され、PW全体に存在するネイバーをターゲットにしているため、トリガーされたJoin（S、G）はすべてのPWで送信されます。
PE2 does not trigger a Join(*,G) based on this Join, since this is a PW-only Join.
これはPWのみの結合であるため、PE2はこの結合に基づくJoin（*、G）をトリガーしません。
PE3 triggers a Join(*,G) targeting CE4. Since the Join(*,G) is targeting a neighbor residing on an AC, it only sends the Join on AC4.
PE3は、CE4をターゲットとするJoin（*、G）をトリガーします。 Join（*、G）はACに常駐するネイバーをターゲットにしているため、AC4にのみJoinを送信します。
6. If traffic is not flowing yet (i.e., step 3 is delayed so that it occurs after step 6) and in the interim JPST(S,G,CE3) on PE1 expires, causing it to send a refresh Join(S,G) targeting CE3, since the refresh Join(S,G) is targeting a neighbor that is residing across a PW, the refresh Join(S,G) is sent on all PWs.
6. トラフィックがまだ流れていない場合（つまり、ステップ3が遅延しているため、ステップ6の後に発生する）、暫定的にPE1のJPST（S、G、CE3）が期限切れになり、リフレッシュ結合（S、G）ターゲティングを送信する場合CE3、リフレッシュJoin（S、G）はPW全体に存在するネイバーをターゲットにしているため、リフレッシュJoin（S、G）はすべてのPWで送信されます。
7. Note that PE1 refreshes its JT based on reception of refresh Joins from CE1 and CE2.
7. PE1は、CE1およびCE2からのリフレッシュ結合の受信に基づいてJTをリフレッシュすることに注意してください。
PE2 consumes the Join(S,G) and refreshes the JT(PW12,S,G,CE3) timer.
PE2はJoin（S、G）を消費し、JT（PW12、S、G、CE3）タイマーを更新します。
PE3 consumes the Join(S,G). It also builds forwarding state on this Join(S,G), even though this is a PW-only Join, since now PE2 has an existing (*,G) state with an AC in UpstreamPorts(*,G). However, since this is a PW-only Join, PE3 only adds the PW towards PE2 (PW23) into UpstreamPorts(S,G) and hence into OutgoingPortList(S,G). It does not add the PW towards PE1 (PW13) into OutgoingPortList(S,G).
PE3はJoin（S、G）を消費します。また、これはPWのみの結合であるにもかかわらず、このJoin（S、G）で転送状態を構築します。これは、PE2がUpstreamPorts（*、G）にACを持つ既存の（*、G）状態を持っているためです。ただし、これはPWのみの結合であるため、PE3はPE2（PW23）へのPWをUpstreamPorts（S、G）に、したがってOutgoingPortList（S、G）に追加するだけです。 PE1（PW13）へのPWをOutgoingPortList（S、G）に追加しません。
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE3 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW13, AC4, PW23 }
Joins are triggered as follows: PE2 already has (S,G) state, so it does not trigger a Join(S,G) based on reception of this refresh Join.
結合は次のようにトリガーされます。PE2にはすでに（S、G）状態があるため、この更新結合の受信に基づいて、Join（S、G）はトリガーされません。
PE3 does not trigger a Join(S,G) based on this Join, since this is a PW-only Join.
これはPWのみの結合であるため、PE3はこの結合に基づくJoin（S、G）をトリガーしません。
8. The multicast stream (S,G) flows into the VPLS from two of the CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to PW12 and PW23. At the same time, PE3 forwards the stream received from CE4 to PW13 and PW23.
8. マルチキャストストリーム（S、G）は、CEの2つであるCE3とCE4からVPLSに流れ込みます。 PE2は、CE3から受信したストリームをPW12およびPW23に転送します。同時に、PE3はCE4から受信したストリームをPW13およびPW23に転送します。
The stream received over PW12 and PW13 is forwarded by PE1 to AC1 and AC2.
PW12およびPW13を介して受信されたストリームは、PE1によってAC1およびAC2に転送されます。
The stream received by PE3 over PW23 is forwarded to AC4. The stream received by PE2 over PW23 is forwarded to AC3. Either of these helps the CE routers to trigger Assert election.
PW23を介してPE3が受信したストリームは、AC4に転送されます。 PW23を介してPE2が受信したストリームは、AC3に転送されます。これらはどちらも、CEルーターがアサート選択をトリガーするのに役立ちます。
9. CE3 and/or CE4 send(s) Assert message(s) to the VPLS. The PEs flood the Assert message(s) without examining it.
9. CE3またはCE4、あるいはその両方がVPLSにメッセージをアサートします。 PEはAssertメッセージを検査せずにフラッディングします。
10. CE3 becomes the (S,G) Assert winner, and CE4 stops sending the multicast stream to the VPLS.
10. CE3は（S、G）アサート勝者となり、CE4はVPLSへのマルチキャストストリームの送信を停止します。
11. CE2 notices an RPF change due to the Assert and sends a Prune(S,G,rpt) with upstream neighbor = CE4.
11. CE2はアサートによるRPFの変更を認識し、上流のネイバー= CE4でPrune（S、G、rpt）を送信します。
12. PE1 consumes the Prune(S,G,rpt), and since PruneDesired(S,G,Rpt,CE4) is TRUE, it triggers a Prune(S,G,rpt) to CE4. Since the Prune is targeting a neighbor across a PW, it is sent on all PWs.
12. PE1はPrune（S、G、rpt）を消費し、PruneDesired（S、G、Rpt、CE4）はTRUEであるため、CE4へのPrune（S、G、rpt）をトリガーします。プルーンはPW全体でネイバーをターゲットにしているため、すべてのPWで送信されます。
PE2 consumes the Prune(S,G,rpt) and does not trigger any Prune based on this Prune(S,G,rpt), since this was a PW-only Prune.
PE2はPrune（S、G、rpt）を消費し、これはPWのみのプルーンであるため、このPrune（S、G、rpt）に基づくプルーンをトリガーしません。
PE3 consumes the Prune(S,G,rpt), and since PruneDesired(S,G,rpt,CE4) is TRUE, it sends the Prune(S,G,rpt) on AC4.
PE3はPrune（S、G、rpt）を消費し、PruneDesired（S、G、rpt、CE4）はTRUEであるため、AC4でPrune（S、G、rpt）を送信します。
PE1 states:
JT(AC2,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
JT(AC2,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamPorts(S,G,rpt) = { PW13 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, AC2 }
PE2 states:
JT(PW12,*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
JT(PW12,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this was created
off a PW-only Prune
UpstreamPorts(S,G,rpt) = { PW23 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(*,G) = { PW12, AC3 }
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
JT(PW13,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamPorts(S,G,rpt) = { AC4 }
JT(PW13,S,G,CE3) = active
JPST(S,G,CE3) = none, since this state is
created by a PW-only Join
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW23 }
Even in this example, at the end of the (S,G) / (*,G) Assert election, there should be no duplicate traffic forwarded downstream, and traffic should flow only to the desired CEs.
この例でも、（S、G）/（*、G）アサート選択の最後に、ダウンストリームに転送される重複トラフィックはなく、トラフィックは目的のCEにのみ流れるはずです。
However, we don't have duplicate traffic because one of the CEs stops sending traffic due to the Assert, not because we don't have any forwarding state in the PEs to do this forwarding.
ただし、CEの1つがアサートのためにトラフィックの送信を停止するためではなく、PEにこの転送を実行する転送状態がないため、トラフィックが重複することはありません。
Acknowledgements
謝辞
Many members of the former L2VPN and PIM working groups have contributed to, and provided valuable comments and feedback on, this document, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lasserre, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah (Ciena), and Himanshu Shah (Cisco).
Vach Kompella、Shane Amante、Sunil Khandekar、Rob Nath、Marc Lasserre、Yuji Kamite、Yiqun Cai、Ali Sajassiなど、以前のL2VPNおよびPIMワーキンググループの多くのメンバーがこのドキュメントに貢献し、貴重なコメントとフィードバックを提供しています。 Jozef Raets、Himanshu Shah（Ciena）、Himanshu Shah（Cisco）。
Contributors
貢献者
Yetik Serbest and Suresh Boddapati coauthored earlier draft versions of this document.
Yetik SerbestとSuresh Boddapatiは、このドキュメントの以前のドラフトバージョンを共同執筆しました。
Karl (Xiangrong) Cai and Princy Elizabeth made significant contributions to bring the specification to its current state, especially in the area of Join forwarding rules.
Karl（Xiangrong）CaiとPrincy Elizabethは、特に結合転送ルールの領域で、仕様を現在の状態にするために多大な貢献をしました。
Authors' Addresses
著者のアドレス
Olivier Dornon Nokia Copernicuslaan 50 B-2018 Antwerp Belgium
Olivier Dornon Nokia Copernicuslaan 50 B-2018 Antwerp Belgium
Email: olivier.dornon@nokia.com
Jayant Kotalwar Nokia 701 East Middlefield Rd. Mountain View, CA 94043 United States of America
Jayant Kotalwar Nokia 701 East Middlefield Rd。マウンテンビュー、カリフォルニア94043アメリカ合衆国
Email: jayant.kotalwar@nokia.com
Venu Hemige Nokia
ヘミゲノキア
Email: vhemige@gmail.com
Ray Qiu mistnet.io
Ray Q IUミストネット.IO
Email: ray@mistnet.io
Jeffrey Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Jeffrey Zhang Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: zzhang@juniper.net