[要約] RFC 7582は、双方向Pトンネルを使用したマルチキャスト仮想プライベートネットワーク（MVPN）に関する規格です。このRFCの目的は、MVPNのパフォーマンスとスケーラビリティを向上させるために、双方向Pトンネルの使用方法を提案することです。
Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 7582 Juniper Networks, Inc.
Updates: 6513, 6514, 6625 IJ. Wijnands
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 Y. Cai
Microsoft
A. Boers
July 2015
Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels
マルチキャスト仮想プライベートネットワーク（MVPN）：双方向Pトンネルの使用
Abstract
概要
A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.
以前のRFCのセットは、BGP / MPLS IP VPNでマルチキャストをサポートするための手順を指定しています。これらの手順により、お客様のマルチキャストデータは、一連のマルチキャストトンネルを介してサービスプロバイダーのバックボーンネットワークを通過できます。トンネルは、「プロバイダーマルチキャストサービスインターフェイス（PMSI）トンネル」属性と呼ばれるBGP属性を使用して、特定のBGPマルチキャスト自動検出ルートでアドバタイズされます。 PMSIトンネル属性が双方向（マルチポイントツーマルチポイント）マルチキャスト配布ツリーを識別できるようにするエンコーディングが定義されています。ただし、以前のRFCは、双方向トンネルを使用してマルチキャストVPNをサポートするために必要なすべての手順を提供していません。このドキュメントでは、これらの手順を指定することにより、RFC 6513、6514、および6625を更新します。特に、顧客のマルチキャストフロー（単方向または双方向）をプロバイダーバックボーン内の特定の双方向トンネルに割り当て、そのような割り当てを通知し、どのフローがどのトンネルに割り当てられているかを判断する手順を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7582.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7582で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Overview ...................................................9
1.2.1. Bidirectional P-Tunnel Technologies ................10
1.2.2. Reasons for Using Bidirectional P-Tunnels ..........11
1.2.3. Knowledge of Group-to-RP and/or
Group-to-RPA Mappings ..............................12
1.2.4. PMSI Instantiation Methods .........................12
2. The All BIDIR-PIM Wildcard .....................................15
3. Using Bidirectional P-Tunnels ..................................15
3.1. Procedures Specific to the Tunneling Technology ...........15
3.1.1. BIDIR-PIM P-Tunnels ................................16
3.1.2. MP2MP LSPs .........................................17
3.2. Procedures Specific to the PMSI Instantiation Method ......17
3.2.1. Flat Partitioning ..................................17
3.2.1.1. When an S-PMSI Is a 'Match for
Transmission' .............................19
3.2.1.2. When an I-PMSI Is a 'Match for
Transmission' .............................20
3.2.1.3. When an S-PMSI Is a 'Match for Reception' .21
3.2.1.4. When an I-PMSI Is a 'Match for Reception' .22
3.2.2. Hierarchical Partitioning ..........................23
3.2.2.1. Advertisement of PE Distinguisher Labels ..24
3.2.2.2. When an S-PMSI Is a 'Match for
Transmission' .............................25
3.2.2.3. When an I-PMSI Is a 'Match for
Transmission' .............................26
3.2.2.4. When an S-PMSI Is a 'Match for Reception' .27
3.2.2.5. When an I-PMSI Is a 'Match for Reception' .27
3.2.3. Unpartitioned ......................................28
3.2.3.1. When an S-PMSI Is a 'Match for
Transmission' .............................30
3.2.3.2. When an S-PMSI Is a 'Match for Reception' .30
3.2.4. Minimal Feature Set for Compliance .................31
4. Security Considerations ........................................32
5. References .....................................................32
5.1. Normative References ......................................32
5.2. Informative References ....................................33
Acknowledgments ...................................................34
Authors' Addresses ................................................34
The RFCs that specify multicast support for BGP/MPLS IP VPNs ([RFC6513], [RFC6514], and [RFC6625]) allow customer multicast data to be transported across a service provider's network though a set of multicast tunnels. These tunnels are advertised in BGP multicast auto-discovery (A-D) routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. The base specifications allow the use of bidirectional (multipoint-to-multipoint) multicast distribution trees and describe how to encode the identifiers for bidirectional trees into the PMSI Tunnel attribute. However, those specifications do not provide all the necessary detailed procedures for using bidirectional tunnels; the full specification of these procedures was considered to be outside the scope of those documents. The purpose of this document is to provide all the necessary procedures for using bidirectional trees in a service provider's network to carry the multicast data of VPN customers.
BGP / MPLS IP VPNのマルチキャストサポートを指定するRFC（[RFC6513]、[RFC6514]、および[RFC6625]）により、顧客のマルチキャストデータを、一連のマルチキャストトンネルを介してサービスプロバイダーのネットワークに転送できます。これらのトンネルは、「プロバイダーマルチキャストサービスインターフェイス（PMSI）トンネル」属性と呼ばれるBGP属性を使用して、BGPマルチキャスト自動検出（A-D）ルートでアドバタイズされます。基本仕様では、双方向（マルチポイントツーマルチポイント）マルチキャスト配信ツリーの使用が許可され、双方向ツリーの識別子をPMSIトンネル属性にエンコードする方法が記述されています。ただし、これらの仕様は、双方向トンネルを使用するために必要なすべての詳細な手順を提供しているわけではありません。これらの手順の完全な仕様は、これらのドキュメントの範囲外であると見なされました。このドキュメントの目的は、サービスプロバイダーのネットワークで双方向ツリーを使用して、VPNカスタマーのマルチキャストデータを伝送するために必要なすべての手順を提供することです。
This document uses terminology from [RFC6513] and, in particular, uses the prefixes "C-" and "P-", as specified in Section 3.1 of [RFC6513], to distinguish addresses in the "customer address space" from addresses in the "provider address space". The following terminology and acronyms are particularly important in this document:
このドキュメントでは、[RFC6513]の用語を使用し、特に、[RFC6513]のセクション3.1で指定されているように、接頭辞「C-」と「P-」を使用して、「顧客アドレススペース」のアドレスと「プロバイダーアドレススペース」。このドキュメントでは、次の用語と頭字語が特に重要です。
o MVPN
o MVPN
Multicast Virtual Private Network -- a VPN [RFC4364] in which multicast service is offered.
マルチキャスト仮想プライベートネットワーク-マルチキャストサービスが提供されるVPN [RFC4364]。
o VRF
o VRF
VPN Routing and Forwarding table [RFC4364].
VPNルーティングおよび転送テーブル[RFC4364]。
o PE
o オン
A Provider Edge router, as defined in [RFC4364].
[RFC4364]で定義されているプロバイダーエッジルーター。
o SP
o SP
Service Provider.
サービスプロバイダー。
o LSP
o LSP
An MPLS Label Switched Path.
MPLSラベルスイッチドパス。
o P2MP
o P2 MP
Point-to-Multipoint.
ポイントツーマルチポイント。
o MP2MP
o MP2MP
Multipoint-to-multipoint.
マルチポイントツーマルチポイント。
o Unidirectional
o 一方向
Adjective for a multicast distribution tree in which all traffic travels downstream from the root of the tree. Traffic can enter a unidirectional tree only at the root. A P2MP LSP is one type of unidirectional tree. Multicast distribution trees set up by Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] are also unidirectional trees. Data traffic traveling along a unidirectional multicast distribution tree is sometimes referred to in this document as "unidirectional traffic".
すべてのトラフィックがツリーのルートから下流に移動するマルチキャスト配信ツリーの形容詞。トラフィックは、ルートでのみ単方向ツリーに入ることができます。 P2MP LSPは、単方向ツリーの一種です。 Protocol Independent Multicast-Sparse Mode（PIM-SM）[RFC4601]によってセットアップされたマルチキャスト配信ツリーも単方向ツリーです。このドキュメントでは、単方向マルチキャスト配信ツリーに沿って移動するデータトラフィックを「単方向トラフィック」と呼ぶことがあります。
o Bidirectional
o 双方向
Adjective for a multicast distribution tree in which traffic may travel both upstream (towards the root) and downstream (away from the root). Traffic may enter a bidirectional tree at any node. An MP2MP LSP is one type of bidirectional tree. Multicast distribution trees created by Bidirectional Protocol Independent Multicast (BIDIR-PIM) [RFC5015] are also bidirectional trees.
トラフィックがアップストリーム（ルートに向かって）とダウンストリーム（ルートから離れて）の両方に移動するマルチキャスト配信ツリーの形容詞。トラフィックは、任意のノードで双方向ツリーに入ります。 MP2MP LSPは、双方向ツリーの1つのタイプです。双方向プロトコル独立マルチキャスト（BIDIR-PIM）[RFC5015]によって作成されたマルチキャスト配信ツリーも、双方向ツリーです。
Data traffic traveling along a bidirectional multicast distribution tree is sometimes referred to in this document as "bidirectional traffic".
このドキュメントでは、双方向マルチキャスト配信ツリーに沿って移動するデータトラフィックを「双方向トラフィック」と呼ぶことがあります。
o P-tunnel
o Pトンネル
A tunnel through the network of one or more SPs. In this document, the P-tunnels we speak of are instantiated as bidirectional multicast distribution trees.
1つ以上のSPのネットワークを通過するトンネル。このドキュメントでは、私たちが話すPトンネルは、双方向マルチキャスト配信ツリーとしてインスタンス化されます。
o SSM
o SSM
Source-Specific Multicast. When SSM is being used, a multicast distribution tree carries traffic from only a single source.
ソース固有のマルチキャスト。 SSMが使用されている場合、マルチキャスト配信ツリーは単一のソースからのトラフィックのみを伝送します。
o ASM
o ASM
Any Source Multicast. When ASM is being used, some multicast distribution trees ("share trees") carry traffic from multiple sources.
任意のソースマルチキャスト。 ASMが使用されている場合、一部のマルチキャスト配信ツリー（「共有ツリー」）は複数のソースからのトラフィックを伝送します。
o C-S
o C-S
Multicast Source. A multicast source address, in the address space of a customer network.
マルチキャストソース。カスタマーネットワークのアドレス空間にあるマルチキャスト送信元アドレス。
o C-G
o C-G
Multicast Group. A multicast group address (destination address) in the address space of a customer network. When used without qualification, "C-G" may refer to either a unidirectional group address or a bidirectional group address.
マルチキャストグループ。カスタマーネットワークのアドレススペース内のマルチキャストグループアドレス（宛先アドレス）。修飾なしで使用される場合、「C-G」は単方向グループアドレスまたは双方向グループアドレスのいずれかを指します。
o C-G-BIDIR
o C-G-BIDIR
A bidirectional multicast group address (i.e., a group address whose IP multicast distribution tree is built by BIDIR-PIM).
双方向マルチキャストグループアドレス（つまり、IPマルチキャスト配布ツリーがBIDIR-PIMによって構築されるグループアドレス）。
o C-multicast flow or C-flow
o CマルチキャストフローまたはCフロー
A customer multicast flow. A C-flow travels through VPN customer sites on a multicast distribution tree set up by the customer. These trees may be unidirectional or bidirectional, depending upon the multicast routing protocol used by the customer. A C-flow travels between VPN customer sites by traveling through P-tunnels.
カスタマーマルチキャストフロー。 Cフローは、カスタマーが設定したマルチキャスト配信ツリー上のVPNカスタマーサイトを通過します。これらのツリーは、顧客が使用するマルチキャストルーティングプロトコルに応じて、単方向または双方向になります。 Cフローは、Pトンネルを経由してVPNカスタマーサイト間を移動します。
A C-flow from a particular customer source is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of such a C-flow is usually written as (C-S,C-G).
特定の顧客ソースからのCフローは、順序付けられたペア（ソースアドレス、グループアドレス）によって識別され、各アドレスは顧客のアドレス空間にあります。このようなCフローの識別子は、通常（C-S、C-G）と表記されます。
If a customer uses the ASM model, then some or all of the customer's C-flows may be traveling along the same "shared tree". In this case, we will speak of a "(C-*,C-G)" flow to refer to a set of C-flows that travel along the same shared tree in the customer sites.
顧客がASMモデルを使用している場合、顧客のCフローの一部またはすべてが同じ「共有ツリー」に沿って移動している可能性があります。この場合、「（C-*、C-G）」フローとは、顧客サイトの同じ共有ツリーに沿って移動する一連のCフローを指します。
o C-BIDIR flow or bidirectional C-flow
o C-BIDIRフローまたは双方向Cフロー
A C-flow that, in the VPN customer sites, travels along a bidirectional multicast distribution tree. The term "C-BIDIR flow" indicates that the customer's bidirectional tree has been set up by BIDIR-PIM.
VPNカスタマーサイトで、双方向マルチキャスト配信ツリーに沿って移動するCフロー。 「C-BIDIRフロー」という用語は、顧客の双方向ツリーがBIDIR-PIMによってセットアップされたことを示します。
o RP
o RP
A Rendezvous Point, as defined in [RFC4601].
[RFC4601]で定義されているランデブーポイント。
o C-RP
o C-RP
A Rendezvous Point whose address is in the customer's address space.
アドレスが顧客のアドレス空間にあるランデブーポイント。
o RPA
o RPA
A Rendezvous Point Address, as defined in [RFC5015].
[RFC5015]で定義されているランデブーポイントアドレス。
o C-RPA
o C-RPA
An RPA in the customer's address space.
顧客のアドレス空間のRPA。
o P-RPA
o P-RPA
An RPA in the SP's address space.
SPのアドレス空間のRPA。
o Selective P-tunnel
o 選択的Pトンネル
A P-tunnel that is joined only by PE routers that need to receive one or more of the C-flows that are traveling through that P-tunnel.
そのPトンネルを通過する1つまたは複数のCフローを受信する必要があるPEルータだけが参加するPトンネル。
o Inclusive P-tunnel
o 包括的なPトンネル
A P-tunnel that is joined by all PE routers that attach to sites of a given MVPN.
特定のMVPNのサイトに接続するすべてのPEルータが参加するPトンネル。
o PMSI
o PMSI
Provider Multicast Service Interface. A PMSI is a conceptual overlay on a Service Provider backbone, allowing a PE in a given MVPN to multicast to other PEs in the MVPN. PMSIs are instantiated by P-tunnels.
プロバイダーマルチキャストサービスインターフェイス。 PMSIは、サービスプロバイダーバックボーン上の概念的なオーバーレイであり、特定のMVPN内のPEがMVPN内の他のPEにマルチキャストできるようにします。 PMSIはPトンネルによってインスタンス化されます。
o I-PMSI
o I-PMSI
Inclusive PMSI. Traffic multicast by a PE on an I-PMSI is received by all other PEs in the MVPN. I-PMSIs are instantiated by Inclusive P-tunnels.
包括的なPMSI。 I-PMSI上のPEによるマルチキャストトラフィックは、MVPN内の他のすべてのPEによって受信されます。 I-PMSIは、インクルーシブPトンネルによってインスタンス化されます。
o S-PMSI
o S-PMSI
Selective PMSI. Traffic multicast by a PE on an S-PMSI is received by some (but not necessarily all) of the other PEs in the MVPN. S-PMSIs are instantiated by Selective P-tunnels.
選択的PMSI。 S-PMSI上のPEによるマルチキャストトラフィックは、MVPN内の他のPEの一部（すべてではない）で受信されます。 S-PMSIは、選択的Pトンネルによってインスタンス化されます。
o Intra-AS I-PMSI A-D route
o AS内I-PMSI A-Dルート
Intra-AS (Autonomous System) Inclusive Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes can be used to advertise the use of Inclusive P-tunnels. See [RFC6514], Section 4.1.
Intra-AS（自律システム）を含むプロバイダーマルチキャストサービスインターフェイスの自動検出ルート。これらのルートは、BGPアップデートメッセージで伝送され、インクルーシブPトンネルの使用をアドバタイズするために使用できます。 [RFC6514]のセクション4.1をご覧ください。
o S-PMSI A-D route
o S-PMSI A-Dルート
Selective Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the fact that a particular C-flow or a particular set of C-flows is bound to (i.e., is traveling through) a particular P-tunnel. See [RFC6514], Section 4.3.
選択的プロバイダーマルチキャストサービスインターフェイスの自動検出ルート。これらのルートは、BGPアップデートメッセージで伝送され、特定のCフローまたはCフローの特定のセットが特定のPトンネルにバインドされている（つまり、通過している）ことを通知するために使用されます。 [RFC6514]のセクション4.3をご覧ください。
o (C-S,C-G) S-PMSI A-D route
o （C-S、C-G）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI (Network Layer Reachability Information) contains C-S in its "Multicast Source" field and C-G in its "Multicast Group" field.
NLRI（ネットワーク層到達可能性情報）の「マルチキャストソース」フィールドにC-S、「マルチキャストグループ」フィールドにC-Gが含まれるS-PMSI A-Dルート。
o (C-*,C-G) S-PMSI A-D route
o （C-*、C-G）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its "Multicast Source" field and C-G in its "Multicast Group" field. See [RFC6625].
NLRIの「マルチキャストソース」フィールドにワイルドカード（C- *）が含まれ、「マルチキャストグループ」フィールドにC-Gが含まれるS-PMSI A-Dルート。 [RFC6625]を参照してください。
o (C-*,C-G-BIDIR) S-PMSI A-D route
o （C-*、C-G-BIDIR）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its "Multicast Source" field and C-G-BIDIR in its "Multicast Group" field. See [RFC6625].
「マルチキャストソース」フィールドにワイルドカード（C- *）が含まれ、「マルチキャストグループ」フィールドにC-G-BIDIRが含まれるS-PMSI A-Dルート。 [RFC6625]を参照してください。
o (C-*,C-*) S-PMSI A-D route
o （C-*、C- *）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its "Multicast Source" field and the wildcard C-* in its "Multicast Group" field. See [RFC6625].
NLRIの「マルチキャストソース」フィールドにワイルドカードC- *が含まれ、「マルチキャストグループ」フィールドにワイルドカードC- *が含まれるS-PMSI A-Dルート。 [RFC6625]を参照してください。
o (C-*,C-*-BIDIR) S-PMSI A-D route
o （C-*、C-*-BIDIR）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its "Multicast Source" field and the wildcard "C-*-BIDIR" in its "Multicast Group" field. See Section 2 of this document.
NLRIの「マルチキャストソース」フィールドにワイルドカードC- *が含まれ、「マルチキャストグループ」フィールドにワイルドカード「C-*-BIDIR」が含まれるS-PMSI A-Dルート。このドキュメントのセクション2を参照してください。
o (C-S,C-*) S-PMSI A-D route
o （C-S、C- *）S-PMSI A-Dルート
An S-PMSI A-D route whose NLRI contains C-S in its "Multicast Source" field and the wildcard C-* in its "Multicast Group" field. See [RFC6625].
NLRIの「マルチキャストソース」フィールドにC-Sが含まれ、「マルチキャストグループ」フィールドにワイルドカードC- *が含まれるS-PMSI A-Dルート。 [RFC6625]を参照してください。
o Wildcard S-PMSI A-D route
o ワイルドカードS-PMSI A-Dルート
A (C-*,C-G) S-PMSI A-D route, a (C-*,C-*) S-PMSI A-D route, a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D route.
（C-*、CG）S-PMSI ADルート、（C-*、C- *）S-PMSI ADルート、（CS、C- *）S-PMSI ADルート、または（C- * 、C-*-BIDIR）S-PMSI ADルート。
o PTA
o 住所
PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. See [RFC6514], Section 8.
PMSIトンネル属性、Pトンネルを識別するBGP属性。 [RFC6514]のセクション8をご覧ください。
The terminology used for categorizing S-PMSI A-D routes will also be used for categorizing the S-PMSIs advertised by those routes. For example, the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known as a "(C-*,C-G) S-PMSI".
S-PMSI A-Dルートの分類に使用される用語は、これらのルートによってアドバタイズされるS-PMSIの分類にも使用されます。たとえば、（C-*、C-G）S-PMSI A-DルートによってアドバタイズされるS-PMSIは、「（C-*、C-G）S-PMSI」と呼ばれます。
Familiarity with multicast concepts and terminology [RFC4601] is also presupposed.
マルチキャストの概念と用語[RFC4601]に精通していることも前提としています。
This specification uses the terms "match for transmission" and "match for reception" as they are defined in [RFC6625]. When it is clear from the context whether we are talking of transmission or reception, we will sometimes talk simply of a C-flow "matching" an I-PMSI or S-PMSI A-D route.
この仕様では、[RFC6625]で定義されている「送信用の一致」と「受信用の一致」という用語を使用します。送信と受信のどちらが話されているかが文脈から明らかな場合は、CフローがI-PMSIまたはS-PMSI A-Dルートに「一致」しているだけの話になることがあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, when and only when appearing in all caps, are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」、すべて大文字で表示される場合とのみ、[RFC2119]で説明されているように解釈されます。
The base documents for MVPN ([RFC6513] and [RFC6514]) define a "PMSI Tunnel attribute" (PTA). This is a BGP Path attribute that may be attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that are defined in those documents. The base documents define the way in which the identifier of a bidirectional P-tunnel is to be encoded in the PTA. However, those documents do not contain the full set of specifications governing the use of bidirectional P-tunnels; rather, those documents declare the full set of specifications for using bidirectional P-tunnels to be outside their scope. Similarly, the use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D routes is declared by [RFC6625] to be "outside the scope" of that document.
MVPNのベースドキュメント（[RFC6513]および[RFC6514]）は、「PMSIトンネル属性」（PTA）を定義しています。これは、これらのドキュメントで定義されているBGP「I-PMSI A-Dルート」および「S-PMSI A-Dルート」に添付できるBGPパス属性です。基本ドキュメントは、双方向Pトンネルの識別子がPTAでエンコードされる方法を定義します。ただし、これらのドキュメントには、双方向Pトンネルの使用を規定する仕様一式が含まれていません。むしろ、これらのドキュメントでは、双方向Pトンネルを使用して範囲外にするための仕様の完全なセットを宣言しています。同様に、ワイルドカードS-PMSI A-Dルートで通知される双方向Pトンネルの使用は、[RFC6625]によって、そのドキュメントの「範囲外」であると宣言されています。
This document provides the specifications governing the use of bidirectional P-tunnels to provide MVPN support. This includes the procedures for assigning C-flows to specific bidirectional P-tunnels, for advertising the fact that a particular C-flow has been assigned to a particular bidirectional P-tunnel, and for determining the bidirectional P-tunnel on which a given C-flow may be expected.
このドキュメントでは、MVPNサポートを提供するための双方向Pトンネルの使用を規定する仕様について説明します。これには、Cフローを特定の双方向Pトンネルに割り当てる手順、特定のCフローが特定の双方向Pトンネルに割り当てられているという事実を通知する手順、および特定のCが存在する双方向Pトンネルを決定する手順が含まれます。 -flowが期待されます。
The C-flows carried on bidirectional P-tunnels may, themselves, be either unidirectional or bidirectional. Procedures are provided for both cases.
双方向Pトンネルで伝送されるCフローは、それ自体が単方向または双方向の場合があります。どちらの場合も手順が示されています。
This document does not specify any new data encapsulations for bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] applies unchanged.
このドキュメントでは、双方向Pトンネルの新しいデータカプセル化は指定していません。 [RFC6513]のセクション12（「カプセル化」）は変更なしに適用されます。
With regard to the procedures for using bidirectional P-tunnels to instantiate PMSIs, if there is any conflict between the procedures specified in this document and the procedures of [RFC6513], [RFC6514], or [RFC6625], the procedures of this document take precedence.
双方向Pトンネルを使用してPMSIをインスタンス化する手順に関して、このドキュメントで指定されている手順と[RFC6513]、[RFC6514]、または[RFC6625]の手順の間に矛盾がある場合、このドキュメントの手順は優先。
The use of bidirectional P-tunnels to support extranets [MVPN-XNET] is outside the scope of this document. The use of bidirectional P-tunnels as "segmented P-tunnels" (see Section 8 of [RFC6513] and various sections of [RFC6514]) is also outside the scope of this document.
エクストラネットをサポートするための双方向Pトンネルの使用[MVPN-XNET]は、このドキュメントの範囲外です。 「セグメント化Pトンネル」としての双方向Pトンネルの使用（[RFC6513]のセクション8および[RFC6514]のさまざまなセクションを参照）も、このドキュメントの範囲外です。
This document supports two different technologies for creating and maintaining bidirectional P-tunnels:
このドキュメントは、双方向Pトンネルを作成および維持するための2つの異なるテクノロジーをサポートしています。
o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that are created through the use of the Label Distribution Protocol (LDP) Multipoint-to-Multipoint extensions [RFC6388].
o ラベル配布プロトコル（LDP）マルチポイントツーマルチポイント拡張[RFC6388]を使用して作成されたマルチポイントツーマルチポイントラベルスイッチドパス（MP2MP LSP）。
o Multicast distribution trees that are created through the use of BIDIR-PIM [RFC5015].
o BIDIR-PIM [RFC5015]を使用して作成されるマルチキャスト配信ツリー。
Other bidirectional tunnel technologies are outside the scope of this document.
他の双方向トンネル技術は、このドキュメントの範囲外です。
Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or S-PMSIs.
双方向Pトンネルを使用して、I-PMSIやS-PMSIをインスタンス化できます。
An SP may decide to use bidirectional P-tunnels to instantiate certain I-PMSIs and/or S-PMSIs in order to provide its customers with C-BIDIR support, using the "Partitioned Set of PEs" technique discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]. This technique can be used whether the C-BIDIR flows are being carried on an I-PMSI or an S-PMSI.
SPは、[RFC6513]のセクション11.2で説明されている「パーティション化されたPEのセット」手法を使用して、顧客にC-BIDIRサポートを提供するために、双方向Pトンネルを使用して特定のI-PMSIまたはS-PMSIをインスタンス化することを決定する場合があります。 ]および[RFC6517]のセクション3.6。この手法は、C-BIDIRフローがI-PMSIまたはS-PMSIで実行されているかどうかに関係なく使用できます。
Even if an SP does not need to provide C-BIDIR support, it may still decide to use bidirectional P-tunnels, in order to save state in the network's transit nodes. For example, if an MVPN has n PEs attached to sites with multicast sources, and there is an I-PMSI for that MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., with P2MP multicast distribution trees) requires n multicast distribution trees, each one rooted at a different PE. If the I-PMSI is instantiated by a bidirectional P-tunnel, a single multicast distribution tree can be used, assuming appropriate support by the provisioning system.
SPがC-BIDIRサポートを提供する必要がない場合でも、ネットワークのトランジットノードの状態を保存するために、双方向Pトンネルを使用することを決定する場合があります。たとえば、MVPNにマルチキャストソースを持つサイトに接続されたn個のPEがあり、そのMVPNのI-PMSIがある場合、単方向Pトンネル（つまり、P2MPマルチキャスト配布ツリー）でI-PMSIをインスタンス化するには、n個のマルチキャスト配布が必要です。それぞれが異なるPEをルートとするツリー。 I-PMSIが双方向Pトンネルによってインスタンス化される場合、プロビジョニングシステムによる適切なサポートを前提として、単一のマルチキャスト配布ツリーを使用できます。
An SP may decide to use bidirectional P-tunnels for either or both of these reasons. Note that even if the reason for using bidirectional P-tunnels is to provide C-BIDIR support, the same P-tunnels can also be used to carry unidirectional C-flows, if that is the choice of the SP.
SPは、これらの理由のいずれかまたは両方のために双方向Pトンネルを使用することを決定する場合があります。双方向Pトンネルを使用する理由がC-BIDIRサポートを提供するためである場合でも、SPを選択する場合は、同じPトンネルを使用して単方向Cフローを伝送することもできます。
These two reasons for using bidirectional P-tunnels may appear to be somewhat in conflict with each other, since (as will be seen in subsequent sections) the use of bidirectional P-tunnels for C-BIDIR support may require multiple bidirectional P-tunnels per VPN. Each such P-tunnel is associated with a particular "distinguished PE", and can only carry those C-BIDIR flows whose C-RPAs are reachable through its distinguished PE. However, on platforms that support MPLS upstream-assigned labels ([RFC5331]), PE Distinguisher Labels (Section 4 of [RFC6513] and Section 8 of [RFC6514]) can be used to aggregate multiple bidirectional P-tunnels onto a single outer bidirectional P-tunnel, thereby allowing one to provide C-BIDIR support with minimal state at the transit nodes.
双方向Pトンネルを使用するこれら2つの理由は、（以降のセクションで説明するように）C-BIDIRサポートに双方向Pトンネルを使用するには、複数の双方向Pトンネルが必要になる場合があるため、互いに矛盾しているように見える場合があります。 VPN。そのような各Pトンネルは、特定の「識別されたPE」に関連付けられ、C-RPAがその区別されたPEを通じて到達可能なC-BIDIRフローのみを伝送できます。ただし、MPLSアップストリーム割り当てラベル（[RFC5331]）をサポートするプラットフォームでは、PE識別ラベル（[RFC6513]のセクション4および[RFC6514]のセクション8）を使用して、複数の双方向Pトンネルを単一の外部双方向に集約できます。 Pトンネル。これにより、トランジットノードでC-BIDIRサポートを最小限の状態で提供できます。
Since there are two fundamentally different reasons for using bidirectional P-tunnels, and since many deployed router platforms do not support upstream-assigned labels at the current time, this document specifies several different methods of using bidirectional P-tunnels to instantiate PMSIs. We refer to these as "PMSI Instantiation Methods". The method or methods deployed by any particular SP will depend upon that SP's goals and engineering trade-offs and upon the set of platforms deployed by that SP.
双方向Pトンネルを使用する根本的に異なる2つの理由があり、展開された多くのルータープラットフォームは現時点でアップストリーム割り当てラベルをサポートしていないため、このドキュメントでは双方向Pトンネルを使用してPMSIをインスタンス化するいくつかの異なる方法を指定します。これらを「PMSIインスタンス化メソッド」と呼びます。特定のSPによって展開されるメソッドは、そのSPの目標とエンジニアリングのトレードオフ、およびそのSPによって展開される一連のプラットフォームに依存します。
The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D routes are not exactly the same as the rules for using unidirectional P-tunnels, and the rules are also different for the different PMSI instantiation methods. Subsequent sections of this document specify the rules in detail.
I-PMSIまたはS-PMSI A-Dルートで双方向Pトンネルを使用するためのルールは、単方向Pトンネルを使用するためのルールとまったく同じではありません。また、ルールはPMSIのインスタンス化方法ごとに異なります。このドキュメントの後続のセクションでは、ルールを詳細に指定します。
If a VPN customer is making use of a particular ASM group address, the PEs of that VPN generally need to know the group-to-RP mappings that are used within the VPN. If a VPN customer is making use of BIDIR-PIM group addresses, the PEs need to know the group-to-RPA mappings that are used within the VPN. Commonly, the PEs obtain this knowledge either through provisioning or by participating in a dynamic "group-to-RP(A) mapping discovery protocol" that runs within the VPN. However, the way in which this knowledge is obtained is outside the scope of this document.
VPNカスタマーが特定のASMグループアドレスを使用している場合、そのVPNのPEは一般に、VPN内で使用されるグループからRPへのマッピングを知る必要があります。 VPNカスタマーがBIDIR-PIMグループアドレスを使用している場合、PEはVPN内で使用されるグループからRPAへのマッピングを知る必要があります。一般に、PEはプロビジョニングを通じて、またはVPN内で実行される動的な「グループからRP（A）へのマッピング検出プロトコル」に参加することによって、この知識を取得します。ただし、この知識を取得する方法は、このドキュメントの範囲外です。
The PEs also need to be able to forward traffic towards the C-RPs and/or C-RPAs and to determine whether the next-hop interface of the route to a particular C-RP(A) is a VRF interface or a PMSI. This is done by applying the procedures of [RFC6513], Section 5.1.
PEは、C-RPやC-RPAにトラフィックを転送し、特定のC-RP（A）へのルートのネクストホップインターフェイスがVRFインターフェイスであるかPMSIであるかを判別できる必要もあります。これは、[RFC6513]のセクション5.1の手順を適用して行われます。
This document specifies three methods for using bidirectional P-tunnels to instantiate PMSIs: two partitioned methods (the Flat Partitioned Method and the Hierarchical Partitioned Method) and the Unpartitioned Method.
このドキュメントでは、双方向Pトンネルを使用してPMSIをインスタンス化するための3つの方法、2つのパーティション方式（フラットパーティション方式と階層型パーティション方式）と非パーティション方式を指定します。
o Partitioned Methods
o 分割されたメソッド
In the Partitioned Methods, a particular PMSI is instantiated by a set of bidirectional P-tunnels. These P-tunnels may be aggregated (as inner P-tunnels) into a single outer bidirectional P-tunnel ("Hierarchical Partitioning"), or they may be unaggregated ("Flat Partitioning"). Any PE that joins one of these P-tunnels can transmit a packet on it, and the packet will be received by all the other PEs that have joined the P-tunnel. For each such P-tunnel (each inner P-tunnel, in the case of Hierarchical Partitioning) there is one PE that is its distinguished PE. When a PE receives a packet from a given P-tunnel, the PE can determine from the packet's encapsulation the P-tunnel it has arrived on, and it can thus infer the identity of the distinguished PE associated with the packet. This association plays an important role in the treatment of the packet, as specified later on in this document.
パーティション方式では、特定のPMSIが双方向Pトンネルのセットによってインスタンス化されます。これらのPトンネルは、（内部Pトンネルとして）単一の外部双方向Pトンネルに集約（「階層分割」）することも、非集約（「フラット分割」）にすることもできます。これらのPトンネルの1つに参加するPEは、その上でパケットを送信でき、そのパケットは、Pトンネルに参加した他のすべてのPEによって受信されます。そのような各Pトンネル（階層分割の場合は、各内部Pトンネル）には、その区別されるPEであるPEが1つあります。 PEが特定のPトンネルからパケットを受信すると、PEはパケットのカプセル化から、到着したPトンネルを判別できるため、パケットに関連付けられている区別されたPEのIDを推測できます。このドキュメントで後述するように、この関連付けはパケットの処理で重要な役割を果たします。
The number of P-tunnels needed (the number of inner P-tunnels needed, if Hierarchical Partitioning is used) depends upon a number of factors that are described later in this document.
必要なPトンネルの数（階層分割が使用されている場合は、必要な内部Pトンネルの数）は、このドキュメントで後述するいくつかの要因によって異なります。
The Hierarchical Partitioned Method requires the use of upstream-assigned MPLS labels (PE Distinguisher Labels) and requires the use of the PE Distinguisher Labels attribute in BGP. The Flat Partitioned Method requires neither of these.
Hierarchical Partitioned Methodでは、アップストリームに割り当てられたMPLSラベル（PE Distinguisher Labels）を使用する必要があり、BGPでPE Distinguisher Labels属性を使用する必要があります。フラットパーティション方式では、これらのどちらも必要ありません。
The Partitioned Method (either Flat or Hierarchical) is a prerequisite for implementing the "Partitioned Sets of PEs" technique of supporting C-BIDIR, as discussed in [RFC6513], Section 11.2. The Partitioned Method (either Flat or Hierarchical) is also a prerequisite for applying the "Discarding Packets from Wrong PE" technique, discussed in [RFC6513], Section 9.1.1, to a PMSI that is instantiated by a bidirectional P-tunnel.
[RFC6513]、セクション11.2で説明されているように、C-BIDIRをサポートする「パーティション化されたPEのセット」手法を実装するには、パーティション化されたメソッド（フラットまたは階層的）が前提条件です。 [RFC6513]のセクション9.1.1で説明されている「間違ったPEからパケットを破棄する」手法を双方向Pトンネルによってインスタンス化されたPMSIに適用するためには、パーティション方式（フラットまたは階層型）も前提条件です。
The Flat Partitioned Method is a prerequisite for implementing the "Partial Mesh of MP2MP P-Tunnels" technique for carrying customer bidirectional (C-BIDIR) traffic, as discussed in [RFC6513], Section 11.2.3.
[RFC6513]、セクション11.2.3で説明されているように、顧客の双方向（C-BIDIR）トラフィックを伝送するための「MP2MP Pトンネルの部分メッシュ」手法を実装するには、フラットパーティション方式が前提条件です。
The Hierarchical Partitioned Method is a prerequisite for implementing the "Using PE Distinguisher Labels" technique of carrying customer bidirectional (C-BIDIR) traffic, as discussed in [RFC6513], Section 11.2.2.
[RFC6513]のセクション11.2.2で説明されているように、顧客の双方向（C-BIDIR）トラフィックを運ぶ「PE Distinguisherラベルの使用」技術を実装するには、階層型分割方式が前提条件です。
Note that a particular deployment may choose to use the Partitioned Methods for carrying the C-BIDIR traffic on bidirectional P-tunnels, while carrying other traffic either on unidirectional P-tunnels or on bidirectional P-tunnels using the Unpartitioned Method. Routers in a given deployment must be provisioned to know which PMSI instantiation method to use for which PMSIs.
特定の展開では、C-BIDIRトラフィックを双方向Pトンネルで伝送するためにパーティション方式を使用する一方で、単方向Pトンネルまたは非パーティション方式を使用して双方向Pトンネルで他のトラフィックを伝送する場合があることに注意してください。特定の展開内のルーターは、どのPMSIにどのPMSIインスタンス化方法を使用するかを知るためにプロビジョニングする必要があります。
There may be ways of implementing the Partitioned Methods with PMSIs that are instantiated by unidirectional P-tunnels. (See, e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the current document.
単方向Pトンネルによってインスタンス化されるPMSIを使用して分割メソッドを実装する方法が存在する場合があります。 （たとえば、[MVPN-BIDIR-IR]を参照してください。）ただし、これは現在のドキュメントの範囲外です。
o Unpartitioned Method
o 分割されていないメソッド
In the Unpartitioned Method, a particular PMSI can be instantiated by a single bidirectional P-tunnel. Any PE that joins the tunnel can transmit a packet on it, and the packet will be received by all the other PEs that have joined the tunnel. The receiving PEs can determine the tunnel on which the packet was transmitted, but they cannot determine which PE transmitted the packet, nor can they associate the packet with any particular distinguished PE.
非パーティション方式では、特定のPMSIを単一の双方向Pトンネルによってインスタンス化できます。トンネルに参加するすべてのPEはその上でパケットを送信でき、パケットはトンネルに参加している他のすべてのPEによって受信されます。受信側PEは、パケットが送信されたトンネルを判別できますが、パケットを送信したPEを判別できません。また、パケットを特定の区別されたPEに関連付けることもできません。
When the Unpartitioned Method is used, this document does not mandate that only one bidirectional P-tunnel be used to instantiate each PMSI. It allows for the case where more than one P-tunnel is used. In this case, the transmitting PEs will have a choice of which such P-tunnel to use when transmitting, and the receiving PEs must be prepared to receive from any of those P-tunnels. The use of multiple P-tunnels in this case provides additional robustness, but it does not provide additional functionality.
Unpartitionedメソッドを使用する場合、このドキュメントでは、各PMSIをインスタンス化するために1つの双方向Pトンネルのみを使用することを義務付けていません。これにより、複数のPトンネルが使用される場合が可能になります。この場合、送信PEは送信時に使用するPトンネルを選択することができ、受信PEはこれらのPトンネルのいずれかから受信できるように準備する必要があります。この場合、複数のPトンネルを使用すると堅牢性が向上しますが、機能は追加されません。
If bidirectional P-tunnels are being used to instantiate the PMSIs of a given MVPN, one of these methods must be chosen for that MVPN. All the PEs of that MVPN must be provisioned to know the method that is being used for that MVPN.
特定のMVPNのPMSIをインスタンス化するために双方向Pトンネルが使用されている場合、そのMVPNに対してこれらの方法のいずれかを選択する必要があります。そのMVPNに使用されている方法を認識するために、そのMVPNのすべてのPEをプロビジョニングする必要があります。
I-PMSIs may be instantiated by bidirectional P-tunnels using either the Partitioned (either Flat or Hierarchical) Methods or the Unpartitioned Method. The method used for a given MVPN is determined by provisioning. It SHOULD be possible to provision this on a per-MVPN basis, but all the VRFs of a single MVPN MUST be provisioned to use the same method for the given MVPN's I-PMSI.
I-PMSIは、分割（フラットまたは階層）メソッドまたは分割されていないメソッドを使用して、双方向Pトンネルによってインスタンス化できます。特定のMVPNに使用される方法は、プロビジョニングによって決定されます。これをMVPNごとにプロビジョニングできるようにする必要がありますが、特定のMVPNのI-PMSIに同じ方法を使用するには、単一のMVPNのすべてのVRFをプロビジョニングする必要があります。
If a bidirectional P-tunnel is used to instantiate an S-PMSI (including the case of a (C-*,C-*) S-PMSI), either the Partitioned Methods (either Flat or Hierarchical) or the Unpartitioned Method may be used. The method used by a given VRF is determined by provisioning. It is desirable to be able to provision this on a per-MVPN basis. All the VRFs of a single MVPN MUST be provisioned to use the same method for those of their S-PMSIs that are instantiated by bidirectional P-tunnels.
双方向Pトンネルを使用してS-PMSI（（C-*、C- *）S-PMSIの場合を含む）をインスタンス化する場合、パーティション化されたメソッド（フラットまたは階層的）または非パーティション化されたメソッドが中古。特定のVRFで使用される方法は、プロビジョニングによって決定されます。これをMVPNごとにプロビジョニングできることが望ましいです。単一のMVPNのすべてのVRFは、双方向Pトンネルによってインスタンス化されるS-PMSIのVRFと同じ方法を使用するようにプロビジョニングする必要があります。
If one of the Partitioned Methods is used, all the VRFs of a single MVPN MUST be provisioned to use the same variant of the Partitioned Methods, i.e., either they must all use the Flat Partitioned Method or they must all use the Hierarchical Partitioned Method.
パーティション分割メソッドの1つを使用する場合、単一のMVPNのすべてのVRFをプロビジョニングして、パーティション分割メソッドの同じバリアントを使用する必要があります。つまり、すべてがフラット分割メソッドを使用するか、すべて階層分割メソッドを使用する必要があります。
It is valid to use the Unpartitioned Method to instantiate the I-PMSIs, while using one of the Partitioned Methods to instantiate the S-PMSIs.
Unpartitionedメソッドを使用してI-PMSIをインスタンス化することは有効ですが、いずれかのPartitionedメソッドを使用してS-PMSIをインスタンス化することもできます。
It is valid to instantiate some S-PMSIs by unidirectional P-tunnels and others by bidirectional P-tunnels.
単方向PトンネルによっていくつかのS-PMSIをインスタンス化し、双方向Pトンネルによって他をインスタンス化することは有効です。
The procedures for the use of bidirectional P-tunnels, specified in subsequent sections of this document, depend on both the tunnel technology and the PMSI instantiation method. Note that this document does not specify procedures for every possible combination of tunnel technology and PMSI instantiation method.
このドキュメントの以降のセクションで指定する双方向Pトンネルの使用手順は、トンネル技術とPMSIインスタンス化方法の両方に依存します。このドキュメントでは、トンネルテクノロジーとPMSIインスタンス化方法のすべての可能な組み合わせの手順を指定しているわけではないことに注意してください。
[RFC6514] specifies the method of encoding C-multicast source and group addresses into the NLRI of certain BGP routes. [RFC6625] extends that specification by allowing the source and/or group address to be replaced by a wildcard. When an MVPN customer is using BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route whose semantics are "by default, all BIDIR-PIM C-multicast traffic (within a given VPN) that has not been bound to any other P-tunnel is bound to the bidirectional P-tunnel identified by the PTA of this route". This can be especially useful if one is using a bidirectional P-tunnel to carry the C-BIDIR flows while using unidirectional P-tunnels to carry other C-flows. To do this, it is necessary to have a way to encode a (C-*,C-*) wildcard that is restricted to BIDIR-PIM C-groups.
[RFC6514]は、Cマルチキャストソースおよびグループアドレスを特定のBGPルートのNLRIにエンコードする方法を指定します。 [RFC6625]は、送信元またはグループアドレス、あるいはその両方をワイルドカードで置き換えることができるようにすることで、その仕様を拡張しています。 MVPNカスタマーがBIDIR-PIMを使用している場合、そのセマンティクスが「デフォルトでは、バインドされていないすべてのBIDIR-PIM Cマルチキャストトラフィック（特定のVPN内）であるS-PMSI ADルートをアドバタイズできると便利です。他のすべてのPトンネルは、このルートのPTAによって識別される双方向Pトンネルにバインドされています。」これは、双方向Pトンネルを使用してC-BIDIRフローを伝送しているときに、単方向Pトンネルを使用して他のCフローを伝送している場合に特に役立ちます。これを行うには、BIDIR-PIM Cグループに制限されている（C-*、C- *）ワイルドカードをエンコードする方法が必要です。
Therefore, we define a special value of the group wildcard, whose meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" is encoded as a group field whose length is 8 bits and whose value is zero. That is, the "multicast group length" field contains the value 0x08, and the "multicast group" field is a single octet containing the value 0x00. (This encoding is distinct from the group wildcard encoding defined in [RFC6625]). We will use the notation (C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard.
したがって、「すべてのBIDIR-PIMグループ」を意味するグループワイルドカードの特別な値を定義します。 「BIDIR-PIMグループワイルドカード」は、長さが8ビットで値がゼロのグループフィールドとしてエンコードされます。つまり、「マルチキャストグループの長さ」フィールドには値0x08が含まれ、「マルチキャストグループ」フィールドには値0x00を含む単一のオクテットがあります。 （このエンコーディングは、[RFC6625]で定義されているグループワイルドカードエンコーディングとは異なります）。 「C-*、C-*-BIDIR」という表記を使用して、「すべてのBIDIR-PIMグループ」のワイルドカードを参照します。
A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS I-PMSI A-D route is outside the scope of this document.
双方向Pトンネルは、Intra-AS I-PMSI A-DルートのPTAまたはS-PMSI A-DルートのPTAでアドバタイズされます。 Inter-AS I-PMSI A-DルートのPTAでの双方向Pトンネルのアドバタイズは、このドキュメントの範囲外です。
This section discusses the procedures that are specific to a given tunneling technology (BIDIR-PIM or the MP2MP procedures of mLDP (Multipoint LDP)) but that are independent of the method (Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) used to instantiate a PMSI.
このセクションでは、所定のトンネリング技術（BIDIR-PIMまたはmLDP（マルチポイントLDP）のMP2MP手順）に固有の手順について説明しますが、PMSIをインスタンス化するために使用される方法（非分割、フラット分割、または階層分割）には依存しません。 。
Each BIDIR-PIM P-tunnel is identified by a unique P-group address ([RFC6513], Section 3.1). (The P-group address is called a "P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route.
各BIDIR-PIM Pトンネルは、一意のPグループアドレスで識別されます（[RFC6513]、セクション3.1）。 （Pグループアドレスは、[RFC6514]では「Pマルチキャストグループ」と呼ばれます）。 [RFC6514]のセクション5は、I-PMSIまたはS-PMSI A-DルートのPTAで特定のBIDIR-PIM Pトンネルを識別する方法を指定しています。
Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM P-tunnels. A BIDIR-PIM P-group address is always associated with a unique Rendezvous Point Address (RPA) in the SP's address space. We will refer to this as the "P-RPA". Every PE needing to join a particular BIDIR-PIM P-tunnel must be able to determine the P-RPA that corresponds to the P-tunnel's P-group address. To construct the P-tunnel, PIM Join/Prune messages are sent along the path from the PE to the P-RPA. Any P routers along that path must also be able to determine the P-RPA, so that they too can send PIM Join/Prune messages towards it. The method of mapping a P-group address to an RPA may be static configuration, or some automated means of RPA discovery that is outside the scope of this specification.
通常のBIDIR-PIM手順は、BIDIR-PIM Pトンネルをセットアップするために使用されます。 BIDIR-PIM Pグループアドレスは、SPのアドレススペース内の一意のランデブーポイントアドレス（RPA）に常に関連付けられています。これを「P-RPA」と呼びます。特定のBIDIR-PIM Pトンネルに参加する必要があるすべてのPEは、PトンネルのPグループアドレスに対応するP-RPAを判別できる必要があります。 Pトンネルを構築するために、PIM Join / Pruneメッセージが、PEからP-RPAへのパスに沿って送信されます。そのパスに沿ったすべてのPルーターも、P-RPAを判別できる必要があります。これにより、PルーターもPIM加入/プルーニングメッセージをその経路に送信できます。 PグループアドレスをRPAにマッピングする方法は、静的構成の場合もあれば、この仕様の範囲外のRPA検出の自動化された手段の場合もあります。
If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to the RPA consist entirely of point-to-point links. On a point-to-point link, there is no ambiguity in determining which router is upstream towards a particular RPA, so the BIDIR-PIM "Designated Forwarder Election" is very quick and simple. Use of a BIDIR-PIM P-tunnel containing multiaccess links is possible, but considerably more complex.
BIDIR-PIM P-tunnelを使用してI-PMSIまたはS-PMSIをインスタンス化する場合、トンネル内の各PEからRPAへのパスが完全にポイントツーポイントリンクで構成されることが推奨されます。ポイントツーポイントリンクでは、特定のRPAへのアップストリームであるルーターを特定するのにあいまいさはありません。そのため、BIDIR-PIMの「Designated Forwarder Election」は非常に迅速かつ簡単です。マルチアクセスリンクを含むBIDIR-PIM Pトンネルの使用は可能ですが、かなり複雑です。
The use of BIDIR-PIM P-tunnels to support the Hierarchical Partitioned Method is outside the scope of this document.
階層パーティション分割方式をサポートするためのBIDIR-PIM Pトンネルの使用は、このドキュメントの範囲外です。
When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT include a PE Distinguisher Labels attribute. If it does, that attribute MUST be ignored. When we say the attribute is "ignored", we do not mean that its normal BGP processing is not done, but that the attribute has no effect on the data plane. However, it MUST be treated by BGP as if it were an unsupported optional transitive attribute. (PE Distinguisher Labels are used for the Hierarchical Partitioning Method, but this document does not provide support for the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.)
Intra-AS I-PMSI A-DルートまたはS-PMSI A-DルートのPTAがBIDIR-PIMトンネルを識別する場合、ルートのオリジネーターは、PE Distinguisher Labels属性を含むべきではありません（SHOULD NOT）。存在する場合、その属性は無視する必要があります。属性が「無視」されているとは、通常のBGP処理が行われないことを意味するのではなく、属性がデータプレーンに影響を与えないことを意味します。ただし、BGPでは、サポートされていないオプションの推移属性であるかのように処理する必要があります。 （PE Distinguisherラベルは階層型パーティション方式に使用されますが、このドキュメントでは、BIDIR-PIM Pトンネルを使用した階層型パーティション方式のサポートは提供していません。）
Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding Equivalence Class) element" [RFC6388]. The FEC element contains the IP address of the root node, followed by an opaque value that identifies the MP2MP LSP uniquely in the context of the root node's IP address. This opaque value may be configured or autogenerated; there is no need for different root nodes to use the same opaque value for a given MVPN.
各MP2MP LSPは、一意の「MP2MP FEC（転送等価クラス）要素」[RFC6388]によって識別されます。 FEC要素には、ルートノードのIPアドレスが含まれ、その後にルートノードのIPアドレスのコンテキストでMP2MP LSPを一意に識別する不透明な値が含まれます。この不透明な値は、構成または自動生成できます。異なるルートノードが特定のMVPNに同じ不透明な値を使用する必要はありません。
The mLDP specification supports the use of several different ways of constructing the tunnel identifiers. The current specification does not place any restriction on the type or types of tunnel identifier that is used in a given deployment. A given implementation is not expected to be able to advertise (in the PTAs of I-PMSI or S-PMSI A-D routes) tunnel identifiers of every possible type. However, an implementation SHOULD be able to accept and properly process a PTA that uses any legal type of tunnel identifier.
mLDP仕様は、トンネル識別子を構築するいくつかの異なる方法の使用をサポートしています。現在の仕様では、特定の展開で使用されるトンネル識別子のタイプに制限はありません。特定の実装では、可能なすべてのタイプのトンネル識別子を（I-PMSIまたはS-PMSI A-DルートのPTAで）通知できるとは限りません。ただし、実装では、正当なタイプのトンネル識別子を使用するPTAを受け入れて適切に処理できる必要があります（SHOULD）。
Section 5 of [RFC6514] specifies the way to identify a particular MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route.
[RFC6514]のセクション5は、I-PMSIまたはS-PMSI A-DルートのPTAで特定のMP2MP Pトンネルを識別する方法を指定しています。
Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP LSP.
MP2MP LSPの通常のmLDP手順は、MP2MP LSPのセットアップに使用されます。
When either the Flat Partitioned Method or the Hierarchical Partitioned Method is used to implement the "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517], a C-BIDIR flow MUST be carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) S-PMSI A-D routes. (Though it may, of course, originate (C-S,C-G) S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.
[RFC6513]のセクション11.2および[RFC6517]のセクション3.6で説明されているように、C-BIDIRをサポートする「パーティション化されたPEのセット」メソッドを実装するためにフラットパーティション化メソッドまたは階層パーティション化メソッドのいずれかが使用される場合、C-BIDIRフローは、I-PMSIまたは（C-*、CG-BIDIR）、（C-*、C-*-BIDIR）、または（C-*、C- *）S-PMSIでのみ実行する必要があります。 PEは、（C-S、C-G-BIDIR）S-PMSI A-Dルートを発信してはなりません（MUST NOT）。 （もちろん、（CS、CG）C-BIDIRグループではないCGのS-PMSI ADルートを発信する可能性があります。）C-BIDIRフローのパケットは、（CS、C- *）S-PMSI。
Sections 3.2.1 and 3.2.2 specify additional details of the two Partitioned Methods.
セクション3.2.1および3.2.2は、2つのパーティション化されたメソッドの追加の詳細を指定します。
The procedures of this section and its subsections apply when (and only when) the Flat Partitioned Method is used. This method is introduced in [RFC6513], Section 11.2.3, where it is called "Partial Mesh of MP2MP P-Tunnels". This method can be used with MP2MP LSPs or with BIDIR-PIM P-tunnels.
このセクションとそのサブセクションの手順は、フラット分割法が使用されている場合にのみ適用されます。この方法は、[RFC6513]のセクション11.2.3で導入されており、「MP2MP Pトンネルの部分メッシュ」と呼ばれています。この方法は、MP2MP LSPまたはBIDIR-PIM Pトンネルで使用できます。
When a PE originates an I-PMSI or S-PMSI A-D route whose PTA specifies a bidirectional P-tunnel, the PE MUST be the root node of the specified P-tunnel.
PEがI-PMSIまたはS-PMSI A-Dルートを発信し、そのPTAが双方向Pトンネルを指定している場合、PEは指定されたPトンネルのルートノードである必要があります。
If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a distinct P-group address. The PE advertising the tunnel will be considered to be the root node of the tunnel. Note that this creates a unique mapping from P-group address to root node. The assignment of P-group addresses to MVPNs is by provisioning.
BIDIR-PIM Pトンネルが使用されている場合、アドバタイズされた各Pトンネルは異なるPグループアドレスを持っている必要があります。トンネルをアドバタイズするPEは、トンネルのルートノードと見なされます。これにより、Pグループアドレスからルートノードへの一意のマッピングが作成されることに注意してください。 MVPNへのPグループアドレスの割り当ては、プロビジョニングによるものです。
If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC (i.e., a distinct combination of root node and opaque value). The PE advertising the tunnel MUST be the same PE identified in the root node field of the MP2MP FEC that is encoded in the PTA.
MP2MP LSPが使用されている場合、各Pトンネルには個別のMP2MP FEC（つまり、ルートノードと不透明な値の個別の組み合わせ）が必要です。トンネルをアドバタイズするPEは、PTAでエンコードされたMP2MP FECのルートノードフィールドで識別される同じPEである必要があります。
It follows that two different PEs may not advertise the same bidirectional P-tunnel. Any PE that receives a packet from the P-tunnel can infer the identity of the P-tunnel from the packet's encapsulation. Once the identity of the P-tunnel is known, the root node of the P-tunnel is also known. The root node of the P-tunnel on which the packet arrived is treated as the distinguished PE for that packet.
したがって、2つの異なるPEが同じ双方向Pトンネルをアドバタイズしない可能性があります。 Pトンネルからパケットを受信するすべてのPEは、パケットのカプセル化からPトンネルのIDを推測できます。 PトンネルのIDがわかると、Pトンネルのルートノードもわかります。パケットが到着したPトンネルのルートノードは、そのパケットの区別されたPEとして扱われます。
The Flat Partitioned Method does not use upstream-assigned labels in the data plane, and hence does not use the BGP PE Distinguisher Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D routes SHOULD NOT contain a PE Distinguisher Labels attribute; if such an attribute is present in a received I-PMSI or S-PMSI A-D route, it MUST be ignored. (When we say the attribute is "ignored", we do not mean that its normal BGP processing is not done, but that the attribute has no effect on the data plane. It MUST, however, be treated by BGP as if it were an unsupported optional transitive attribute.)
Flat Partitioned Methodは、データプレーンでアップストリームに割り当てられたラベルを使用しないため、BGP PE Distinguisher Labels属性を使用しません。この方法を使用する場合、I-PMSIおよび/またはS-PMSI A-Dルートには、PE Distinguisher Labels属性を含めないでください。そのような属性が受信されたI-PMSIまたはS-PMSI A-Dルートに存在する場合、それは無視されなければなりません（MUST）。 （属性が「無視される」と言った場合、通常のBGP処理が行われないことを意味するのではなく、属性がデータプレーンに影響を与えないことを意味します。ただし、BGPはそれがサポートされていないオプションの推移属性。）
When the Flat Partitioned Method is used to instantiate the I-PMSIs of a given MVPN, every PE in that MVPN that originates an Intra-AS I-PMSI A-D route MUST include a PTA that specifies a bidirectional P-tunnel. If the intention is to carry C-BIDIR traffic on the I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of its VRF interfaces is the next-hop interface on its best path to the C-RPA of any bidirectional C-group of the MVPN.
Flat Partitioned Methodを使用して特定のMVPNのI-PMSIをインスタンス化する場合、Intra-AS I-PMSI A-Dルートを発信するそのMVPN内のすべてのPEには、双方向Pトンネルを指定するPTAを含める必要があります。意図がI-PMSIでC-BIDIRトラフィックを運ぶことである場合、VRFインターフェイスの1つがC-RPAへの最良のパスのネクストホップインターフェイスである場合、PEはIntra-AS I-PMSI ADルートを発信する必要があります。 MVPNの双方向Cグループ。
When the Flat Partitioned Method is used to instantiate a (C-*,C-*) S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE that originates the corresponding S-PMSI A-D route MUST include in that route a PTA specifying a bidirectional P-tunnel. Per the procedures of [RFC6513] and [RFC6514], a PE will originate such an S-PMSI A-D route only if one of the PE's VRF interfaces is the next- hop interface of the PE's best path to the C-RPA of a C-BIDIR group that is to be carried on the specified S-PMSI.
（C-*、C- *）S-PMSI、（C-*、C-*-BIDIR）S-PMSI、または（C-*、CG-BIDIR）をインスタンス化するためにフラットパーティション方式が使用される場合S-PMSI、対応するS-PMSI ADルートを発信するPEは、そのルートに双方向Pトンネルを指定するPTAを含める必要があります。 [RFC6513]と[RFC6514]の手順に従って、PEのVRFインターフェイスの1つがCのC-RPAへのPEの最適パスのネクストホップインターフェイスである場合にのみ、PEはそのようなS-PMSI ADルートを発信します指定されたS-PMSIで実行される-BIDIRグループ。
PMSIs that are instantiated via the Flat Partitioned Method may carry customer bidirectional traffic AND customer unidirectional traffic. The rules of Sections 3.2.1.1 and 3.2.1.2 determine when a given customer multicast packet is a match for transmission to a given PMSI. However, if the "Partitioned Set of PEs" method of supporting C-BIDIR traffic is being used for a given MVPN, the PEs must be provisioned in such a way that packets from a C-BIDIR flow of that MVPN never match any PMSI that is not instantiated by a bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*) S-PMSI were not instantiated by a bidirectional P-tunnel, one could meet this requirement by carrying all C-BIDIR traffic of that MVPN on a (C-*,C-*-BIDIR) S-PMSI.)
フラットパーティション方式を介してインスタンス化されたPMSIは、顧客の双方向トラフィックと顧客の単方向トラフィックを伝送します。セクション3.2.1.1および3.2.1.2のルールは、特定のカスタマーマルチキャストパケットが特定のPMSIへの送信に一致する場合を決定します。ただし、C-BIDIRトラフィックをサポートする「パーティション化されたPEのセット」方式が特定のMVPNに使用されている場合、そのMVPNのC-BIDIRフローからのパケットが、どのPMSIにも一致しないようにPEをプロビジョニングする必要があります。双方向Pトンネルによってインスタンス化されません。 （たとえば、特定のMVPNの（C-*、C- *）S-PMSIが双方向Pトンネルによってインスタンス化されなかった場合、そのMVPNのすべてのC-BIDIRトラフィックを（C- *、C-*-BIDIR）S-PMSI）
When a PE receives a customer multicast data packet from a bidirectional P-tunnel, it associates that packet with a distinguished PE. The distinguished PE for a given packet is the root node of the tunnel from which the packet is received. The rules of Sections 3.2.1.1 and 3.2.1.2 ensure that:
PEが双方向Pトンネルからカスタマーマルチキャストデータパケットを受信すると、そのパケットを区別されたPEに関連付けます。特定のパケットの識別されたPEは、パケットの受信元であるトンネルのルートノードです。セクション3.2.1.1および3.2.1.2のルールにより、以下が保証されます。
o If the received packet is part of a unidirectional C-flow, its distinguished PE is the PE that transmitted the packet onto the P-tunnel.
o 受信したパケットが単方向Cフローの一部である場合、その区別されるPEは、パケットをPトンネルに送信したPEです。
o If the received packet is part of a bidirectional C-flow, its distinguished PE is not necessarily the PE that transmitted it, but rather the transmitter's upstream PE [RFC6513] for the C-RPA of the bidirectional C-group.
o 受信したパケットが双方向のCフローの一部である場合、その区別されたPEは、必ずしもパケットを送信したPEではなく、双方向のCグループのC-RPAに対するトランスミッタのアップストリームPE [RFC6513]です。
The rules of Sections 3.2.1.3 and 3.2.1.4 allow the receiving PEs to determine the expected distinguished PE for each C-flow, and ensure that a packet will be discarded if its distinguished PE is not the expected distinguished PE for the C-flow to which the packet belongs. This prevents duplication of data for both bidirectional and unidirectional C-flows.
セクション3.2.1.3および3.2.1.4のルールにより、受信PEはCフローごとに期待される区別されたPEを決定でき、その区別されたPEがCフローに対して期待される区別されたPEでない場合、パケットが確実に破棄されます。パケットが属するもの。これにより、双方向と単方向の両方のCフローのデータの重複が防止されます。
Suppose a given PE, say PE1, needs to transmit multicast data packets of a particular C-flow. Section 3.1 of [RFC6625] gives a four-step algorithm for determining the S-PMSI A-D route, if any, that matches that C-flow for transmission.
特定のPE、たとえばPE1が特定のCフローのマルチキャストデータパケットを送信する必要があるとします。 [RFC6625]のセクション3.1は、S-PMSI A-Dルートを決定するための4ステップのアルゴリズムを示しています。
If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; the remainder of this section applies only to C-BIDIR flows. If a C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 are given below:
CフローがBIDIR-PIM Cフローでない場合、これらのルールは変更されずに適用されます。このセクションの残りの部分は、C-BIDIRフローにのみ適用されます。 C-BIDIRフローにグループアドレスC-G-BIDIRがある場合、PE1によって適用されるルールは以下のとおりです。
o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's route to the C-RPA is via a VRF interface, then:
o C-G-BIDIRのC-RPAがPE1のCアドレスである場合、またはC-RPAへのPE1のルートがVRFインターフェイス経由の場合、次のようになります。
* If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently originated by PE1, then the C-flow matches that route.
* 現在PE1が発信した（C-*、C-G-BIDIR）S-PMSI A-Dルートがある場合、Cフローはそのルートに一致します。
* Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route currently originated by PE1, then the C-flow matches that route.
* それ以外の場合で、現在PE1によって発信された（C-*、C-*-BIDIR）S-PMSI A-Dルートがある場合、Cフローはそのルートに一致します。
* Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently originated by PE1, then the C-flow matches that route.
* それ以外の場合、PE1が現在発信している（C-*、C- *）S-PMSI A-Dルートがある場合、Cフローはそのルートに一致します。
o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some other PE, say PE2, then:
o PE1がC-G-BIDIRのC-RPAのアップストリームPEを他のPE、たとえばPE2であると決定した場合、次のようになります。
* If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then the C-flow matches that route.
* インストールされている（C-*、C-G-BIDIR）S-PMSI A-DルートがPE2から発信されている場合、C-flowはそのルートに一致します。
* Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then the C-flow matches that route.
* それ以外の場合、インストールされている（C-*、C-*-BIDIR）S-PMSI A-DルートがPE2によって発信されていると、Cフローはそのルートに一致します。
* Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route originated by PE2, then the C-flow matches that route.
* それ以外の場合、インストールされている（C-*、C- *）S-PMSI A-DルートがPE2によって発信されていれば、Cフローはそのルートに一致します。
If there is an S-PMSI A-D route that matches a given C-flow, and if PE1 needs to transmit packets of that C-flow or other PEs, then it MUST transmit those packets on the bidirectional P-tunnel identified in the PTA of the matching S-PMSI A-D route.
特定のCフローに一致するS-PMSI ADルートがあり、PE1がそのCフローまたは他のPEのパケットを送信する必要がある場合、それらのパケットは、次のPTAで識別される双方向Pトンネルで送信する必要があります。一致するS-PMSI ADルート。
Suppose a given PE, say PE1, needs to transmit packets of a given C-flow (of a given MVPN) to other PEs, but according to the conditions of Section 3.2.1.1 and/or Section 3.1 of [RFC6625], that C-flow does not match any S-PMSI A-D route. Then, the packets of the C-flow need to be transmitted on the MVPN's I-PMSI.
特定のPE、たとえばPE1が（特定のMVPNの）特定のCフローのパケットを他のPEに送信する必要があると仮定しますが、[RFC6625]のセクション3.2.1.1またはセクション3.1、あるいはその両方に従って、そのC -flowはどのS-PMSI ADルートとも一致しません。次に、C-flowのパケットをMVPNのI-PMSIで送信する必要があります。
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the C-flow MUST be transmitted is the one identified in the PTA of the Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN.
CフローがBIDIR-PIM Cフローでない場合、Cフローを送信する必要があるPトンネルは、PE1が発信したIntra-AS I-PMSI ADルートのPTAで識別されたものである必要があります。 MVPNを与えられた。
If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the rules applied by PE1 are:
CフローがグループアドレスがC-G-BIDIRのBIDIR-PIM Cフローである場合、PE1によって適用されるルールは次のとおりです。
o Suppose that the C-RPA for C-G-BIDIR is a C-address of PE1, or that PE1's route to the C-RPA is via a VRF interface. Then, if there is an I-PMSI A-D route currently originated by PE1, the C-flow MUST be transmitted on the P-tunnel identified in the PTA of that I-PMSI A-D route.
o C-G-BIDIRのC-RPAがPE1のCアドレスであるか、またはC-RPAへのPE1のルートがVRFインターフェイスを経由するとします。次に、PE1が現在発信しているI-PMSI A-Dルートがある場合、Cフローは、そのI-PMSI A-DルートのPTAで識別されたPトンネルで送信する必要があります。
o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some other PE, say PE2, then if there is an installed I-PMSI A-D route originated by PE2, the C-flow MUST be transmitted on the P-tunnel identified in the PTA of that route.
o PE1がCG-BIDIRのC-RPAのアップストリームPEを他のPE、たとえばPE2であると判断した場合、PE2から発信されたインストール済みのI-PMSI ADルートがある場合、識別されたPトンネルでCフローを送信する必要がありますそのルートのPTAで。
If there is no I-PMSI A-D route meeting the above conditions, the C-flow MUST NOT be transmitted.
上記の条件を満たすI-PMSI A-Dルートがない場合、Cフローを送信してはならない（MUST NOT）。
Suppose a given PE, say PE1, needs to receive multicast data packets of a particular C-flow. Section 3.2 of [RFC6625] specifies procedures for determining the S-PMSI A-D route, if any, that matches that C-flow for reception. Those rules apply unchanged for C-flows that are not BIDIR-PIM C-flows. The remainder of this section applies only to C-BIDIR flows.
特定のPE、たとえばPE1が特定のCフローのマルチキャストデータパケットを受信する必要があるとします。 [RFC6625]のセクション3.2は、受信のためにそのCフローと一致するS-PMSI A-Dルートがある場合は、それを決定するための手順を指定しています。これらのルールは、BIDIR-PIM CフローではないCフローには変更されずに適用されます。このセクションの残りの部分は、C-BIDIRフローにのみ適用されます。
The rules of [RFC6625], Section 3.2.1, are not applicable to C-BIDIR flows. The rules of [RFC6625], Section 3.2.2, are replaced by the following rules.
[RFC6625]のセクション3.2.1のルールは、C-BIDIRフローには適用されません。 [RFC6625]のセクション3.2.2のルールは、次のルールに置き換えられます。
Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also that PE1 has determined that PE2 is the upstream PE [RFC6513] for the C-RPA of C-G-BIDIR. Then:
PE1が（C-*、C-G-BIDIR）トラフィックを受信する必要があるとします。また、PE1が、PE2がC-G-BIDIRのC-RPAのアップストリームPE [RFC6513]であると判断したと仮定します。次に：
o If PE1 is not the same as PE2, and PE1 has an installed (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
o PE1がPE2と同じではなく、PE1にPE2によって発信された（C-*、C-G-BIDIR）S-PMSI A-Dルートがインストールされている場合、（C-*、C-G-BIDIR）はこのルートに一致します。
o Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.
o それ以外の場合、PE1がPE2と同じで、PE1が現在（C-*、C-G-BIDIR）S-PMSI A-Dルートを発信している場合、（C-*、C-G-BIDIR）はこのルートに一致します。
o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
o それ以外の場合、PE1がPE2と同じではなく、PE1にPE2によって発信された（C-*、C-*-BIDIR）S-PMSI A-Dルートがインストールされている場合、（C-*、C-G-BIDIR）はこのルートに一致します。
o Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.
o それ以外の場合、PE1がPE2と同じで、PE1が現在（C-*、C-*-BIDIR）S-PMSI A-Dルートを発信している場合、（C-*、C-G-BIDIR）はこのルートに一致します。
o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches this route.
o それ以外の場合、PE1がPE2と同じではなく、PE1にPE2から発信された（C-*、C- *）S-PMSI A-Dルートがインストールされている場合、（C-*、C-G-BIDIR）はこのルートに一致します。
o Otherwise, if PE1 is the same as PE2, and PE1 has currently originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this route.
o それ以外の場合、PE1がPE2と同じで、PE1が現在（C-*、C- *）S-PMSI A-Dルートを発信している場合、（C-*、C-G-BIDIR）はこのルートに一致します。
If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according to these rules, the root node of that P-tunnel is considered to be the distinguished PE for that (C-*,C-G-BIDIR) flow. If a (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is not the distinguished PE for the C-flow, the packet MUST be discarded.
S-PMSI ADルートマッチング（C-*、CG-BIDIR）がある場合、これらのルールに従って、そのPトンネルのルートノードはその（C-*、CG-BIDIRの識別されたPEであると見なされます。 ）フロー。 （C-*、C-G-BIDIR）パケットが、ルートノードがCフローの区別されたPEではないPトンネルで受信された場合、パケットは破棄されなければなりません（MUST）。
Suppose a given PE, say PE1, needs to receive packets of a given C-flow (of a given MVPN) from another PE, but according to the conditions of Section 3.2.1.3 and/or Section 3.2 of [RFC6625], that C-flow does not match any S-PMSI A-D route. Then, the packets of the C-flow need to be received on the MVPN's I-PMSI.
特定のPE、たとえばPE1が別のPEから（特定のMVPNの）特定のCフローのパケットを受信する必要があると仮定しますが、[RFC6625]のセクション3.2.1.3および/またはセクション3.2の条件に従って、そのC -flowはどのS-PMSI ADルートとも一致しません。次に、C-flowのパケットをMVPNのI-PMSIで受信する必要があります。
If the C-flow is not a BIDIR-PIM C-flow, the rules for determining the P-tunnel on which packets of the C-flow are expected are given in [RFC6513]. The remainder of this section applies only to C-BIDIR flows.
CフローがBIDIR-PIM Cフローでない場合、Cフローのパケットが期待されるPトンネルを決定するためのルールは、[RFC6513]に記載されています。このセクションの残りの部分は、C-BIDIRフローにのみ適用されます。
Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other PEs. Suppose also that PE1 has determined that PE2 is the upstream PE [RFC6513] for the C-RPA of C-G-BIDIR. Then, PE1 considers PE2 to be the distinguished PE for (C-*,C-G-BIDIR). If PE1 has an installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will expect to receive packets of the C-flow from the tunnel specified in that route's PTA. (If all VRFs of the MVPN have been properly provisioned to use the Flat Partitioned Method for the I-PMSI, the PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one currently originated by PE1.
PE1が他のPEから（C-*、C-G-BIDIR）トラフィックを受信する必要があるとします。また、PE1が、PE2がC-G-BIDIRのC-RPAのアップストリームPE [RFC6513]であると判断したと仮定します。次に、PE1はPE2を（C-*、C-G-BIDIR）の識別PEと見なします。 PE1に、PE2から発信されたIntra-AS I-PMSI A-Dルートがインストールされている場合、PE1は、そのルートのPTAで指定されたトンネルからCフローのパケットを受信することを期待します。 （MVPNのすべてのVRFがI-PMSIのフラットパーティション方式を使用するように適切にプロビジョニングされている場合、PTAは双方向Pトンネルを指定します。）PE1がPE2と同じ場合、関連するイントラAS I-PMSI ADルートは、現在PE1が発信しているルートです。
If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the expected one, the packet MUST be discarded.
（C-*、C-G-BIDIR）パケットが予期されたもの以外のPトンネルで受信された場合、パケットは破棄されなければなりません（MUST）。
The procedures of this section and its subsections apply when (and only when) the Hierarchical Partitioned Method is used. This method is introduced in [RFC6513], Section 11.2.2. This document only provides procedures for using this method when using MP2MP LSPs as the P-tunnels.
このセクションとそのサブセクションの手順は、階層型分割手法が使用されている場合にのみ適用されます。この方法は、[RFC6513]のセクション11.2.2で紹介されています。このドキュメントでは、MP2MP LSPをPトンネルとして使用する場合にこの方法を使用する手順のみを説明しています。
The Hierarchical Partitioned Method provides the same functionality as the Flat Partitioned Method, but it requires a smaller amount of state to be maintained in the core of the network. However, it requires the use of upstream-assigned MPLS labels ("PE Distinguisher Labels"), which are not necessarily supported by all hardware platforms. The upstream-assigned labels are used to provide an LSP hierarchy, in which an outer MP2MP LSP carries multiple inner MP2MP LSPs. Transit routers along the path between PE routers then only need to maintain state for the outer MP2MP LSP.
階層分割メソッドは、フラット分割メソッドと同じ機能を提供しますが、ネットワークのコアで維持する必要がある状態の量が少なくなります。ただし、アップストリームに割り当てられたMPLSラベル（「PE Distinguisher Labels」）を使用する必要があります。これは、すべてのハードウェアプラットフォームでサポートされているとは限りません。アップストリームに割り当てられたラベルは、LSP階層を提供するために使用されます。LSP階層では、外部MP2MP LSPが複数の内部MP2MP LSPを伝送します。 PEルーター間のパスに沿った中継ルーターは、外部MP2MP LSPの状態を維持するだけで済みます。
When this method is used to instantiate a particular PMSI, the bidirectional P-tunnel advertised in the PTA of the corresponding I-PMSI or S-PMSI A-D route is the outer P-tunnel. When a packet is received from a P-tunnel, the PE that receives it can infer the identity of the outer P-tunnel from the MPLS label that has risen to the top of the packet's label stack. However, the packet's distinguished PE is not necessarily the root node of the outer P-tunnel. Rather, the identity of the packet's distinguished PE is inferred from the PE Distinguisher Label further down in the label stack. (See [RFC6513], Section 12.3.) The PE Distinguisher Label may be thought of as identifying an inner MP2MP LSP whose root is the PE corresponding to that label.
この方法を使用して特定のPMSIをインスタンス化する場合、対応するI-PMSIまたはS-PMSI A-DルートのPTAでアドバタイズされる双方向Pトンネルは、外部Pトンネルです。パケットがPトンネルから受信されると、それを受信するPEは、パケットのラベルスタックの最上位に上昇したMPLSラベルから外部PトンネルのIDを推測できます。ただし、パケットの区別されたPEは、必ずしも外部Pトンネルのルートノードではありません。むしろ、パケットの識別されたPEのIDは、ラベルスタックのさらに下のPE Distinguisher Labelから推測されます。 （[RFC6513]のセクション12.3を参照してください。）PE識別ラベルは、そのラベルに対応するPEをルートとする内部MP2MP LSPを識別するものと考えることができます。
In the context of a given MVPN, if it is desired to use the Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes MUST be originated by some of the PEs that attach to that MVPN. The PEs that are REQUIRED to originate these routes are those that satisfy one of the following conditions:
特定のMVPNのコンテキストで、階層型パーティション方式を使用してI-PMSI、（C-*、C- *）S-PMSI、または（C-*、C-*- BIDIR）S-PMSI、対応するADルートは、そのMVPNに接続するPEの一部によって発信されなければなりません（MUST）。これらのルートを発信する必要があるPEは、次のいずれかの条件を満たすものです。
o There is a C-BIDIR group for which the best path from the PE to the C-RPA of that C-group is via a VRF interface.
o PEからそのCグループのC-RPAへの最適なパスがVRFインターフェイスを経由するC-BIDIRグループがあります。
o The PE might have to transmit unidirectional customer multicast traffic on the PMSI identified in the route (of course this condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) S-PMSIs).
o PEは、ルートで識別されたPMSIで単方向カスタマーマルチキャストトラフィックを送信する必要がある場合があります（もちろん、この条件は（C-*、C-*-BIDIR）または（C-*、CG-BIDIR）S-には適用されません） PMSI）。
o The PE is the root node of the MP2MP LSP that is used to instantiate the PMSI.
o PEは、PMSIをインスタンス化するために使用されるMP2MP LSPのルートノードです。
When the Hierarchical Partitioned method is used to instantiate a (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI route MUST NOT be originated by a given PE unless either (a) that PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D route.
（C-*、CG-BIDIR）S-PMSIをインスタンス化するために階層パーティション方式が使用される場合、対応する（C-*、CG-BIDIR）S-PMSIルートは、いずれかの（a ）CG-BIDIRのC-RPAへのPEの最適パスはVRFインターフェイスを経由するか、または（b）C-RPAはPEのCアドレスです。さらに、そのPEは、S-PMSI A-DルートのPTAで識別されるMP2MP LSPのルートノードである必要があります。
If any VRF of a given MVPN uses this method to instantiate an S-PMSI with a bidirectional P-tunnel, all VRFs of that MVPN must use this method.
特定のMVPNのいずれかのVRFがこの方法を使用して、双方向PトンネルでS-PMSIをインスタンス化する場合、そのMVPNのすべてのVRFがこの方法を使用する必要があります。
Suppose that for a given MVPN, the Hierarchical Partitioned Method is used to instantiate the I-PMSI. In general, more than one of the PEs in the MVPN will originate an Intra-AS I-PMSI A-D route for that MVPN. This document allows the PTAs of those routes to all specify the same MP2MP LSP as the "outer tunnel". However, it does not require that those PTAs all specify the same MP2MP LSP as the outer tunnel. By having all the PEs specify the same outer tunnel for the I-PMSI, one can minimize the amount of state in the transit nodes. By allowing them to specify different outer tunnels, one uses more state, but may increase the robustness of the system.
特定のMVPNについて、階層型パーティション方式を使用してI-PMSIをインスタンス化するとします。一般に、MVPN内の複数のPEが、そのMVPNのIntra-AS I-PMSI A-Dルートを発信します。このドキュメントでは、これらのルートのPTAがすべて「外部トンネル」と同じMP2MP LSPを指定できるようにしています。ただし、それらのPTAがすべて同じMP2MP LSPを外部トンネルとして指定する必要はありません。すべてのPEでI-PMSIに同じ外部トンネルを指定することで、トランジットノードの状態の量を最小限に抑えることができます。異なる外部トンネルを指定できるようにすることで、より多くの状態を使用できますが、システムの堅牢性が向上する可能性があります。
The considerations of the previous paragraph apply as well when the Hierarchical Partitioned Method is used to instantiate an S-PMSI.
S-PMSIをインスタンス化するために階層型分割メソッドが使用される場合にも、前の段落の考慮事項が適用されます。
A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] that can be used, in the context of an MP2MP LSP, to denote a particular PE that either has joined or may in the future join that LSP.
PE Distinguisher Labelはアップストリームに割り当てられたMPLSラベル[RFC5331]であり、MP2MP LSPのコンテキストで、そのLSPに参加した、または将来参加する可能性のある特定のPEを示すために使用できます。
In order to use upstream-assigned MPLS labels in the context of an outer MP2MP LSP, there must be a convention that identifies a particular router as the router that is responsible for allocating the labels and for advertising the labels to the PEs that may join the MP2MP LSP. This document REQUIRES that the PE Distinguisher Labels used in the context of a given MP2MP LSP be allocated and advertised by the router that is the root node of the LSP.
アップストリームに割り当てられたMPLSラベルを外部MP2MP LSPのコンテキストで使用するには、特定のルーターを、ラベルの割り当てと、PEに参加するPEへのラベルのアドバタイズを担当するルーターとして識別する規則が必要です。 MP2MP LSP。このドキュメントでは、特定のMP2MP LSPのコンテキストで使用されるPE識別ラベルが、LSPのルートノードであるルーターによって割り当てられ、アドバタイズされる必要があります。
This convention accords with the rules of Section 7 of [RFC5331]. Note that according to Section 7 of [RFC5331], upstream-assigned labels are unique in the context of the IP address of the root node; if two MP2MP LSPs have the same root node IP address, the upstream-assigned labels used within the two LSPs come from the same label space.
この規則は、[RFC5331]のセクション7の規則に準拠しています。 [RFC5331]のセクション7によると、上流に割り当てられたラベルはルートノードのIPアドレスのコンテキストで一意であることに注意してください。 2つのMP2MP LSPに同じルートノードIPアドレスがある場合、2つのLSP内で使用されるアップストリーム割り当てのラベルは、同じラベルスペースから取得されます。
This document assumes that the root node address of an MP2MP LSP is an IP address that is uniquely assigned to the node. The use of an "anycast address" as the root node address is outside the scope of this document.
このドキュメントでは、MP2MP LSPのルートノードアドレスが、ノードに一意に割り当てられるIPアドレスであると想定しています。ルートノードアドレスとしての「エニーキャストアドレス」の使用は、このドキュメントの範囲外です。
A PE Distinguisher Labels attribute SHOULD NOT be attached to an I-PMSI or S-PMSI A-D route unless that route also contains a PTA that specifies an MP2MP LSP. (While PE Distinguisher Labels could in theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such use is outside the scope of this document.)
PE Distinguisher Labels属性は、そのルートにMP2MP LSPを指定するPTAも含まれていない限り、I-PMSIまたはS-PMSI A-Dルートにアタッチすべきではありません（SHOULD NOT）。 （PE Distinguisher Labelsは理論的にはPTAがBIDIR-PIM P-tunnelを指定している場合にも使用できますが、そのような使用はこのドキュメントの範囲外です。）
The PE Distinguisher Labels attribute specifies a set of <MPLS label, IP address> bindings. Within a given PE Distinguisher Labels attribute, each such IP address MUST appear at most once, and each MPLS label MUST appear only once. Otherwise, the attribute is considered to be malformed, and the "treat-as-withdraw" error-handling approach described in Section 2 of [BGP-ERROR] MUST be used.
PE Distinguisher Labels属性は、<MPLSラベル、IPアドレス>バインディングのセットを指定します。特定のPE Distinguisher Labels属性内では、そのような各IPアドレスは最大で1回出現する必要があり、各MPLSラベルは1回だけ出現する必要があります。それ以外の場合、属性は不正な形式と見なされ、[BGP-ERROR]のセクション2で説明されている "treat-as-withdraw"エラー処理アプローチを使用する必要があります。
When a PE Distinguisher Labels attribute is included in a given I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address of each of the following PEs:
PE Distinguisher Labels属性が特定のI-PMSIまたはS-PMSI A-Dルートに含まれている場合、次の各PEのIPアドレスにラベルを割り当てる必要があります。
o The root node of the MP2MP LSP identified in the PTA of the route.
o ルートのPTAで識別されたMP2MP LSPのルートノード。
o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR group.
o C-BIDIRグループのC-RPAの入力PEである可能性のあるPE。
o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP LSP identified in the PTA of the route.
o ルートのPTAで識別されたMP2MP LSPで非C-BIDIRトラフィックを送信する必要があるすべてのPE。
One simple way to meet these requirements is to assign a PE Distinguisher label to every PE that has originated an Intra-AS I-PMSI A-D route.
これらの要件を満たす簡単な方法の1つは、Intra-AS I-PMSI A-Dルートを発信したすべてのPEにPE Distinguisherラベルを割り当てることです。
Suppose a given PE, say PE1, needs to transmit multicast data packets of a particular C-flow. Section 3.1 of [RFC6625] gives a four-step algorithm for determining the S-PMSI A-D route, if any, that matches that C-flow for transmission.
特定のPE、たとえばPE1が特定のCフローのマルチキャストデータパケットを送信する必要があるとします。 [RFC6625]のセクション3.1は、S-PMSI A-Dルートを決定するための4ステップのアルゴリズムを示しています。
If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged. If there is a matching S-PMSI A-D route, the P-tunnel on which the C-flow MUST be transmitted is the one identified in the PTA of the matching route. Each packet of the C-flow MUST carry the PE Distinguisher Label assigned by the root node of that P-tunnel to the IP address of PE1. See Section 12.3 of [RFC6513] for encapsulation details.
CフローがBIDIR-PIM Cフローでない場合、それらのルールは変更されずに適用されます。一致するS-PMSI A-Dルートがある場合、Cフローが送信されるPトンネルは、一致するルートのPTAで識別されたものである必要があります。 Cフローの各パケットは、そのPトンネルのルートノードによってPE1のIPアドレスに割り当てられたPE識別ラベルを運ぶ必要があります。カプセル化の詳細については、[RFC6513]のセクション12.3を参照してください。
The remainder of this section applies only to C-BIDIR flows. If a C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 are the same as the rules given in Section 3.2.1.1.
このセクションの残りの部分は、C-BIDIRフローにのみ適用されます。 C-BIDIRフローにグループアドレスC-G-BIDIRがある場合、PE1によって適用されるルールは、セクション3.2.1.1に示されているルールと同じです。
If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow on the P-tunnel identified in its PTA. Suppose PE1 has determined that PE2 is the upstream PE for the C-RPA of the given C-flow. In constructing the packet's MPLS label stack, PE1 must use the PE Distinguisher Label that was assigned by the P-tunnel's root node to the IP address of "PE2", not the label assigned to the IP address of "PE1" (unless, of course, PE1 is the same as PE2). See Section 12.3 of [RFC6513] for encapsulation details. Note that the root of the P-tunnel might be a PE other than PE1 or PE2.
一致するS-PMSI A-Dルートがある場合、PE1は、PTAで識別されたPトンネルでCフローを送信する必要があります。 PE1が、PE2が特定のCフローのC-RPAのアップストリームPEであると判断したとします。パケットのMPLSラベルスタックを構築する際、PE1は、Pトンネルのルートノードによって「PE2」のIPアドレスに割り当てられたPE識別ラベルを使用する必要があります。もちろん、PE1はPE2と同じです）。カプセル化の詳細については、[RFC6513]のセクション12.3を参照してください。 Pトンネルのルートは、PE1またはPE2以外のPEである可能性があることに注意してください。
Suppose a given PE, say PE1, needs to transmit packets of a given C-flow (of a given MVPN) to other PEs, but according to the conditions of Section 3.2.2.2 and/or Section 3.1 of [RFC6625], that C-flow does not match any S-PMSI A-D route. Then the packets of the C-flow need to be transmitted on the MVPN's I-PMSI.
特定のPE、たとえばPE1が特定のCフロー（特定のMVPNの）のパケットを他のPEに送信する必要があると仮定しますが、[RFC6625]のセクション3.2.2.2および/またはセクション3.1の条件に従って、そのC -flowはどのS-PMSI ADルートとも一致しません。次に、CフローのパケットをMVPNのI-PMSIで送信する必要があります。
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the C-flow MUST be transmitted is the one identified in the PTA of the Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each packet of the C-flow MUST carry the PE Distinguisher Label assigned by the root node of that P-tunnel to the IP address of PE1.
CフローがBIDIR-PIM Cフローでない場合、Cフローを送信する必要があるPトンネルは、PE1が発信したIntra-AS I-PMSI ADルートのPTAで識別されたものである必要があります。 MVPNを与えられた。 Cフローの各パケットは、そのPトンネルのルートノードによってPE1のIPアドレスに割り当てられたPE識別ラベルを運ぶ必要があります。
If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the rules as applied by PE1 are the same as those given in Section 3.2.1.2.
CフローがグループアドレスがC-G-BIDIRのBIDIR-PIM Cフローである場合、PE1によって適用されるルールは、セクション3.2.1.2と同じです。
If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow on the P-tunnel identified in its PTA. In constructing the packet's MPLS label stack, it must use the PE Distinguisher Label that was assigned by the P-tunnel's root node to the IP address of "PE2", not the label assigned to the IP address of "PE1" (unless, of course, PE1 is the same as PE2). (Section 3.2.1.2 specifies the difference between PE1 and PE2.) See Section 12.3 of [RFC6513] for encapsulation details. Note that the root of the P-tunnel might be a PE other than PE1 or PE2.
一致するI-PMSI A-Dルートがある場合、PE1は、PTAで識別されたPトンネルでCフローを送信する必要があります。パケットのMPLSラベルスタックを構築する場合、Pトンネルのルートノードによって「PE1」のIPアドレスに割り当てられたラベルではなく、「PE2」のIPアドレスに割り当てられたPE識別ラベルを使用する必要があります。もちろん、PE1はPE2と同じです）。 （セクション3.2.1.2は、PE1とPE2の違いを指定しています。）カプセル化の詳細については、[RFC6513]のセクション12.3を参照してください。 Pトンネルのルートは、PE1またはPE2以外のPEである可能性があることに注意してください。
If, for a packet of a particular C-flow, there is no S-PMSI A-D route or I-PMSI A-D route that is a match for transmission, the packet MUST NOT be transmitted.
特定のCフローのパケットについて、送信に一致するS-PMSI A-DルートまたはI-PMSI A-Dルートがない場合、パケットは送信してはなりません（MUST NOT）。
Suppose a given PE, say PE1, needs to receive multicast data packets of a particular C-flow. Section 3.2 of [RFC6625] specifies procedures for determining the S-PMSI A-D route, if any, that matches that C-flow for reception. Those rules require that the matching S-PMSI A-D route has been originated by the upstream PE for the C-flow. The rules are modified in this section, as follows:
特定のPE、たとえばPE1が特定のCフローのマルチキャストデータパケットを受信する必要があるとします。 [RFC6625]のセクション3.2は、受信のためにそのCフローと一致するS-PMSI A-Dルートがある場合は、それを決定するための手順を指定しています。これらのルールでは、一致するS-PMSI A-DルートがCフローのアップストリームPEによって発信されている必要があります。このセクションでは、次のようにルールが変更されています。
Consider a particular C-flow. Suppose either:
特定のCフローを考えてみましょう。次のいずれかを想定します。
o the C-flow is unidirectional, and PE1 determines that its upstream PE is PE2, or
o Cフローは単方向であり、PE1はそのアップストリームPEがPE2であると判断します。
o the C-flow is bidirectional, and PE1 determines that the upstream PE for its C-RPA is PE2
o Cフローは双方向であり、PE1はC-RPAのアップストリームPEがPE2であると判断します
Then, the C-flow may match an installed S-PMSI A-D route that was not originated by PE2, as long as:
次に、Cフローは、次の条件が満たされる限り、PE2から発信されていない、インストールされているS-PMSI A-Dルートと一致する可能性があります。
1. the PTA of that A-D route identifies an MP2MP LSP,
1. そのA-DルートのPTAはMP2MP LSPを識別し、
2. there is an installed S-PMSI A-D route originated by the root node of that LSP, or PE1 itself is the root node of the LSP and there is a currently originated S-PMSI A-D route from PE1 whose PTA identifies that LSP, and
2. そのLSPのルートノードによって発信されたインストール済みのS-PMSI A-Dルートがある、またはPE1自体がLSPのルートノードであり、PTAがそのLSPを識別するPE1から現在発信されたS-PMSI A-Dルートがある。
3. the latter S-PMSI A-D route (the one identified in 2 just above) contains a PE Distinguisher Labels attribute that assigned an MPLS label to the IP address of PE2.
3. 後者のS-PMSI A-Dルート（上記の2で識別されたもの）には、MPLSラベルをPE2のIPアドレスに割り当てたPE Distinguisher Labels属性が含まれています。
However, a bidirectional C-flow never matches an S-PMSI A-D route whose NLRI contains (C-S,C-G).
ただし、双方向Cフローは、NLRIに（C-S、C-G）が含まれるS-PMSI A-Dルートと一致しません。
If a multicast data packet is received over a matching P-tunnel, but does not carry the value of the PE Distinguisher Label that has been assigned to the upstream PE for its C-flow, then the packet MUST be discarded.
マルチキャストデータパケットが一致するPトンネルを介して受信されたが、CフローのアップストリームPEに割り当てられたPE識別ラベルの値を運ばない場合、パケットは破棄されなければなりません（MUST）。
If a PE needs to receive packets of a given C-flow (of a given MVPN) from another PE, and if, according to the conditions of Section 3.2.2.4, that C-flow does not match any S-PMSI A-D route, then the packets of the C-flow need to be received on the MVPN's I-PMSI. The P-tunnel on which the packets are expected to arrive is determined by the Intra-AS I-PMSI A-D route originated by the distinguished PE for the given C-flow. The PTA of that route specifies the "outer P-tunnel" and thus determines the top label that packets of that C-flow will be carrying when received. A PE that needs to receive packets of a given C-flow must determine the expected value of the second label for packets of that C-flow. This will be the value of a PE Distinguisher Label, taken from the PE Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of the root node of that outer tunnel. The expected value of the second label on received packets (corresponding to the "inner tunnel") of a given C-flow is determined according to the following rules.
PEが別のPEから（特定のMVPNの）特定のCフローのパケットを受信する必要があり、セクション3.2.2.4の条件に従って、そのCフローがどのS-PMSI ADルートとも一致しない場合、次に、C-flowのパケットをMVPNのI-PMSIで受信する必要があります。パケットが到着すると予想されるPトンネルは、特定のCフローの区別されたPEによって開始されたIntra-AS I-PMSI A-Dルートによって決定されます。そのルートのPTAは「外部Pトンネル」を指定し、したがって、受信時にそのCフローのパケットが運ぶことになるトップラベルを決定します。特定のCフローのパケットを受信する必要があるPEは、そのCフローのパケットの2番目のラベルの期待値を決定する必要があります。これは、その外部トンネルのルートノードのIntra-AS I-PMSI A-DルートのPE Distinguisher Labels属性から取得したPE Distinguisher Labelの値になります。特定のCフローの受信パケット（「内部トンネル」に対応）の2番目のラベルの期待値は、次のルールに従って決定されます。
First, the distinguished PE for the C-flow is determined:
最初に、Cフローの識別PEが決定されます。
o If the C-flow is not a BIDIR-PIM C-flow, the distinguished PE for the C-flow is its upstream PE, as determined by the rules of [RFC6513].
o C-flowがBIDIR-PIM C-flowではない場合、[RFC6513]のルールで決定されているように、C-flowの識別PEはその上流PEです。
o If the C-flow is a BIDIR-PIM C-flow, the distinguished PE for the C-flow is its upstream PE of the C-flow's C-RPA, as determined by the rules of [RFC6513].
o C-flowがBIDIR-PIM C-flowである場合、C-flowの区別されたPEは、[RFC6513]のルールによって決定されるように、C-flowのC-RPAの上流PEです。
The expected value of the second label is the value that the root PE of the outer tunnel has assigned, in the PE Distinguisher Labels attribute of its Intra-AS I-PMSI A-D route, to the IP address of the distinguished PE.
2番目のラベルの期待値は、外部トンネルのルートPEが、そのIntra-AS I-PMSI A-DルートのPE Distinguisher Labels属性で、識別されたPEのIPアドレスに割り当てた値です。
Packets addressed to C-G that arrive on other than the expected inner and outer P-tunnels (i.e., that arrive with unexpected values of the top two labels) MUST be discarded.
予想される内部および外部Pトンネル以外に到着するC-G宛てのパケット（つまり、上位2つのラベルの予期しない値で到着するパケット）は破棄する必要があります。
When a particular MVPN uses the Unpartitioned Method of instantiating an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route that includes a PTA specifying a bidirectional P-tunnel. The conditions under which an Intra-AS I-PMSI A-D route must be originated from a given VRF are as specified in [RFC6514]. This document allows all but one of such routes to omit the PTA. However, each such route MAY contain a PTA. If the PTA is present, it MUST specify a bidirectional P-tunnel. As specified in [RFC6513] and [RFC6514], every PE that imports such an Intra-AS I-PMSI A-D route into one of its VRFs MUST, if the route has a PTA, join the P-tunnel specified in the route's PTA.
特定のMVPNが双方向PトンネルでI-PMSIをインスタンス化するパーティション化されていない方法を使用する場合、そのMVPNの少なくとも1つのVRFが、指定するPTAを含むIntra-AS I-PMSI ADルートを発信する必要があります。双方向Pトンネル。 AS内I-PMSI A-Dルートが特定のVRFから発信されなければならない条件は、[RFC6514]で指定されているとおりです。このドキュメントでは、そのようなルートの1つを除くすべてでPTAを省略できます。ただし、そのような各ルートにはPTAが含まれる場合があります。 PTAが存在する場合は、双方向Pトンネルを指定する必要があります。 [RFC6513]と[RFC6514]で指定されているように、そのようなIntra-AS I-PMSI A-DルートをVRFの1つにインポートするすべてのPEは、ルートにPTAがある場合、ルートのPTAで指定されたPトンネルに参加する必要があります。
Packets received on any of these P-tunnels are treated as having been received over the I-PMSI. The disposition of a received packet MUST NOT depend upon the particular P-tunnel over which it has been received.
これらのPトンネルのいずれかで受信されたパケットは、I-PMSI経由で受信されたものとして扱われます。受信されたパケットの後処理は、それが受信された特定のPトンネルに依存してはならない（MUST NOT）。
When a PE needs to transmit a packet on such an I-PMSI, then if that PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route that it originated, the PE SHOULD transmit the on that P-tunnel. However, any PE that transmits a packet on the I-PMSI MAY transmit it on any of the P-tunnels advertised in any of the currently installed Intra-AS I-PMSI A-D routes for its VPN.
PEがそのようなI-PMSIでパケットを送信する必要がある場合、そのPEが元のAS内I-PMSI ADルートのPTAでPトンネルをアドバタイズした場合、PEはそのP-トンネル。ただし、I-PMSIでパケットを送信するすべてのPEは、VPNに現在インストールされている任意のAS内I-PMSI A-Dルートでアドバタイズされた任意のPトンネルでパケットを送信できます（MAY）。
This allows a single bidirectional P-tunnel to be used to instantiate the I-PMSI, but also allows the use of multiple bidirectional P-tunnels. There may be a robustness advantage in having multiple P-tunnels available for use, but the number of P-tunnels used does not impact the functionality in any way. If there are, e.g., two P-tunnels available, these procedures allow each P-tunnel to be advertised by a single PE, but they also allow each P-tunnel to be advertised by multiple PEs. Note that the PE advertising a given P-tunnel does not have to be the root node of the tunnel. The root node might not even be a PE router, and it might not originate any BGP routes at all.
これにより、単一の双方向Pトンネルを使用してI-PMSIをインスタンス化できますが、複数の双方向Pトンネルを使用することもできます。複数のPトンネルを使用できるようにすると、堅牢性が向上する可能性がありますが、使用されるPトンネルの数が機能に影響を与えることはありません。たとえば、2つのPトンネルが利用可能な場合、これらの手順により、各Pトンネルを単一のPEによってアドバタイズできますが、各Pトンネルを複数のPEによってアドバタイズすることもできます。特定のPトンネルをアドバタイズするPEは、トンネルのルートノードである必要はないことに注意してください。ルートノードはPEルーターでなくても、BGPルートをまったく発信しない可能性があります。
In the Unpartitioned Method, packets received on the I-PMSI cannot be associated with a distinguished PE, so duplicate detection using the techniques of Section 9.1.1 of [RFC6513] is not possible; the techniques of Sections 9.1.2 or 9.1.3 of [RFC6513] would have to be used instead. Support for C-BIDIR using the "Partitioned set of PEs" technique (Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]) is not possible when the Unpartitioned Method is used. If it is desired to use that technique to support C-BIDIR, but also to use the Unpartitioned Method to instantiate the I-PMSI, then all the C-BIDIR traffic would have to be carried on an S-PMSI, where the S-PMSI is instantiated using one of the Partitioned Methods.
分割されていない方法では、I-PMSIで受信されたパケットを区別されたPEに関連付けることができないため、[RFC6513]のセクション9.1.1の手法を使用した重複検出は不可能です。代わりに、[RFC6513]のセクション9.1.2または9.1.3の手法を使用する必要があります。 「パーティション化されたPEのセット」手法（[RFC6513]のセクション11.2および[RFC6517]のセクション3.6）を使用したC-BIDIRのサポートは、パーティション化されていないメソッドが使用されている場合は不可能です。 C-BIDIRをサポートするためにその手法を使用したいが、非パーティション化メソッドを使用してI-PMSIをインスタンス化したい場合は、すべてのC-BIDIRトラフィックをS-PMSIで伝送する必要があります。 PMSIは、パーティション化されたメソッドの1つを使用してインスタンス化されます。
When a PE, say PE1, needs to transmit multicast data packets of a particular C-flow to other PEs, and PE1 does not have an S-PMSI that is a match for transmission for that C-flow (see Section 3.2.3.1), PE1 transmits the packets on one of the P-tunnel(s) that instantiates the I-PMSI. When a PE, say PE1, needs to receive multicast data packets of a particular C-flow from another PE, and PE1 does not have an S-PMSI that is a match for reception for that C-flow (see Section 3.2.3.2), PE1 expects to receive the packets on any of the P-tunnels that instantiate the I-PMSI.
PE、たとえばPE1が特定のCフローのマルチキャストデータパケットを他のPEに送信する必要があり、PE1がそのCフローの送信に一致するS-PMSIを持っていない場合（セクション3.2.3.1を参照） 、PE1は、I-PMSIをインスタンス化するPトンネルの1つでパケットを送信します。 PE、たとえばPE1が特定のCフローのマルチキャストデータパケットを別のPEから受信する必要があり、PE1がそのCフローの受信に一致するS-PMSIを持っていない場合（セクション3.2.3.2を参照） 、PE1は、I-PMSIをインスタンス化するPトンネルのいずれかでパケットを受信することを期待しています。
When a particular MVPN uses the Unpartitioned Method to instantiate a (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional P-tunnel, the same conditions apply as when an I-PMSI is instantiated via the Unpartitioned Method. The only difference is that a PE need not join a P-tunnel that instantiates the S-PMSI unless that PE needs to receive multicast packets on the S-PMSI.
特定のMVPNが非パーティション方式を使用して、（C-*、C- *）S-PMSIまたは（C-*、C-*-BIDIR）S-PMSIを双方向Pトンネルを使用してインスタンス化する場合、同じ条件が適用されますI-PMSIがUnpartitionedメソッドを介してインスタンス化されるときのように。唯一の違いは、PEがS-PMSIでマルチキャストパケットを受信する必要がない限り、PEはS-PMSIをインスタンス化するPトンネルに参加する必要がないことです。
When a particular MVPN uses bidirectional P-tunnels to instantiate other S-PMSIs, different S-PMSI A-D routes that do not contain (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different PEs, MAY have PTAs that identify the same bidirectional tunnel, and they MAY have PTAs that do not identify the same bidirectional tunnel.
特定のMVPNが双方向Pトンネルを使用して他のS-PMSIをインスタンス化する場合、（C-*、C- *）または（C-*、C-*-BIDIR）を含まない異なるS-PMSI ADルートは、同じまたは異なるPEによって、同じ双方向トンネルを識別するPTAがあり、同じ双方向トンネルを識別しないPTAがある場合があります。
While the Unpartitioned Method MAY be used to instantiate an S-PMSI to which one or more C-BIDIR flows are bound, it must be noted that the "Partitioned Set of PEs" method discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517] cannot be supported using the Unpartitioned Method. C-BIDIR support would have to be provided by the procedures of [RFC6513], Section 11.1.
Unpartitionedメソッドは、1つ以上のC-BIDIRフローがバインドされているS-PMSIをインスタンス化するために使用できますが、[RFC6513]のセクション11.2およびセクション3.6で説明されている「Partitioned Set of PEs」メソッドに注意する必要があります。 [RFC6517]は、分割されていない方法を使用してサポートできません。 C-BIDIRサポートは、[RFC6513]、セクション11.1の手順で提供する必要があります。
Suppose a PE needs to transmit multicast data packets of a particular customer C-flow. [RFC6625], Section 3.1, gives a four-step algorithm for determining the S-PMSI A-D route, if any, that matches that C-flow for transmission. When referring to that section, please recall that BIDIR-PIM groups are also ASM groups.
PEが特定の顧客のCフローのマルチキャストデータパケットを送信する必要があるとします。 [RFC6625]のセクション3.1は、S-PMSI A-Dルートを決定するための4ステップアルゴリズムを示しています。このセクションを参照するときは、BIDIR-PIMグループもASMグループであることを思い出してください。
When bidirectional P-tunnels are used in the Unpartitioned Method, the same algorithm applies, with one modification, when the PTA of an S-PMSI A-D route identifies a bidirectional P-tunnel. One additional step is added to the algorithm. This new step occurs before the fourth step of the algorithm, and is as follows:
パーティション分割されていない方法で双方向Pトンネルが使用される場合、S-PMSI A-DルートのPTAが双方向Pトンネルを識別するときに、同じアルゴリズムが適用されますが、1つの変更が適用されます。アルゴリズムにステップが1つ追加されます。この新しいステップは、アルゴリズムの4番目のステップの前に発生し、次のようになります。
o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route currently originated by PE1, and if C-G is a BIDIR group, the C-flow matches that route.
o それ以外の場合、現在PE1が発信した（C-*、C-*-BIDIR）S-PMSI A-Dルートがある場合、C-GがBIDIRグループの場合、C-flowはそのルートに一致します。
When the Unpartitioned Method is used, the PE SHOULD transmit the C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D route, but it MAY transmit the C-flow on any P-tunnel that is advertised in the PTA of any installed S-PMSI A-D route that contains the same (C-S,C-G) as the matching S-PMSI A-D route.
Unpartitionedメソッドが使用される場合、PEは、一致するS-PMSI ADルートででアドバタイズされるPトンネルでCフローを送信する必要がありますが、一致するS-PMSI ADルートと同じ（CS、CG）を含む、インストールされているS-PMSI ADルートのPTA。
Suppose a PE needs to receive multicast data packets of a particular customer C-flow. Section 3.2 of [RFC6625] specifies the procedures for determining the S-PMSI A-D route, if any, that advertised the P-tunnel on which the PE should expect to receive that C-flow.
PEが特定の顧客のCフローのマルチキャストデータパケットを受信する必要があるとします。 [RFC6625]のセクション3.2は、PEがそのCフローを受信することを期待するPトンネルをアドバタイズするS-PMSI A-Dルートを決定するための手順を指定しています。
When bidirectional P-tunnels are used in the Unpartitioned Method, the same procedures apply, with one modification.
パーティション化されていない方法で双方向Pトンネルを使用する場合、1つの変更を加えた同じ手順が適用されます。
The last paragraph of Section 3.2.2 of [RFC6625] begins:
[RFC6625]のセクション3.2.2の最後の段落が始まります。
If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the following conditions holds:
（C-*、CG）がPE2からの（C-*、CG）S-PMSI ADルートと一致しないが、PE1にPE2からの（C-*、C- *）S-PMSI ADルートがインストールされている場合、 （C-*、CG）は、次のいずれかの条件が満たされた場合、（C-*、C- *）ルートと一致します。
This is changed to:
これは次のように変更されます。
If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, but C-G is a BIDIR group and PE1 has an installed (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the following conditions holds:
（C-*、CG）がPE2からの（C-*、CG）S-PMSI ADルートと一致しないが、CGはBIDIRグループであり、PE1に（C-*、C-*-BIDIR）Sがインストールされている場合-PMSI ADルートの場合、（C-*、CG）はそのルートに一致します。それ以外の場合、PE1にPE2からの（C-*、C- *）S-PMSI ADルートがインストールされている場合、次のいずれかの条件の場合、（C-*、CG）は（C-*、C- *）ルートと一致します。保持：
When the Unpartitioned Method is used, the PE MUST join the P-tunnel that is advertised in the matching S-PMSI A-D route, and it MUST also join the P-tunnels that are advertised in other installed S-PMSI A-D routes that contain the same (C-S,C-G) as the matching S-PMSI A-D route.
Unpartitionedメソッドが使用される場合、PEは、一致するS-PMSI ADルートでアドバタイズされるPトンネルに参加する必要があり、また、それを含む他のインストール済みS-PMSI ADルートでアドバタイズされるPトンネルに参加する必要があります。一致するS-PMSI ADルートと同じ（CS、CG）。
Implementation of bidirectional P-tunnels is OPTIONAL. If bidirectional P-tunnels are not implemented, the issue of compliance to this specification does not arise. However, for the case where bidirectional P-tunnels ARE implemented, this section specifies the minimal set of features that MUST be implemented in order to claim compliance to this specification.
双方向Pトンネルの実装はオプションです。双方向Pトンネルが実装されていない場合、この仕様への準拠の問題は発生しません。ただし、双方向Pトンネルが実装されている場合、このセクションでは、この仕様への準拠を主張するために実装する必要がある機能の最小セットを指定します。
In order to be compliant with this specification, an implementation that provides bidirectional P-tunnels MUST support at least one of the two P-tunnel technologies mentioned in Section 1.2.1.
この仕様に準拠するために、双方向Pトンネルを提供する実装は、セクション1.2.1で言及されている2つのPトンネル技術の少なくとも1つをサポートする必要があります。
A PE that does not provide C-BIDIR support using the "partitioned set of PEs" method is deemed compliant to this specification if it supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR-PIM multicast distribution trees as P-tunnels.
MP2MP LSPまたはBIDIR-PIMマルチキャスト配布ツリーをPトンネルとして使用する非パーティション化メソッドをサポートする場合、「パーティション化されたPEのセット」メソッドを使用してC-BIDIRサポートを提供しないPEは、この仕様に準拠していると見なされます。
A PE that does provide C-BIDIR support using the "partitioned set of PEs" method MUST, at a minimum, be able to provide C-BIDIR support using the "Partial Mesh of MP2MP P-tunnels" variant of this method (see Section 11.2 of [RFC6513]). An implementation will be deemed compliant to this minimum requirement if it can carry all of a VPN's C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a bidirectional P-tunnel, using the Flat Partitioned Method.
「PEのパーティション化されたセット」メソッドを使用してC-BIDIRサポートを提供するPEは、少なくとも、このメソッドの「MP2MP Pトンネルの部分メッシュ」バリアントを使用してC-BIDIRサポートを提供できなければなりません（セクションを参照）。 [RFC6513]の11.2）。を使用して、双方向Pトンネルによってインスタンス化された（C-*、C-*-BIDIR）S-PMSIでVPNのすべてのC-BIDIRトラフィックを伝送できる場合、実装はこの最小要件に準拠していると見なされます。フラット分割法。
There are no additional security considerations beyond those of [RFC6513] and [RFC6514], or any that may apply to the particular protocol used to set up the bidirectional tunnels ([RFC5015], [RFC6388]).
[RFC6513]と[RFC6514]のセキュリティに関する考慮事項、または双方向トンネルのセットアップに使用される特定のプロトコル（[RFC5015]、[RFC6388]）以外のセキュリティに関する考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、DOI 10.17487 / RFC4601 、2006年8月、<http://www.rfc-editor.org/info/rfc4601>。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<http：/ /www.rfc-editor.org/info/rfc5015>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、DOI 10.17487 / RFC6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、DOI 10.17487 / RFC6513、February 2012、<http：//www.rfc-editor .org / info / rfc6513>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< http://www.rfc-editor.org/info/rfc6514>。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャストVPNオートディスカバリルートのワイルドカード」、RFC 6625、DOI 10.17487 / RFC6625、2012年5月、<http://www.rfc-editor.org/info/rfc6625>。
[BGP-ERROR] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, draft-ietf-idr-error-handling-19, April 2015.
[BGP-ERROR] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、and K. Patel、 "Revised Error Handling for BGP UPDATE Messages"、Work in Progress、draft-ietf-idr -error-handling-19、2015年4月。
[MVPN-BIDIR-IR] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating 'Partial Mesh of MP2MP P-Tunnels' with Ingress Replication", Work in Progress, draft-ietf-bess-mvpn-bidir-ingress-replication-00, January 2015.
[MVPN-BIDIR-IR] Zhang、Z.、Rekhter、Y。、およびA. Dolganow、「「イングレスレプリケーションによるMP2MP Pトンネルの部分メッシュ」のシミュレーション」、進行中の作業、draft-ietf-bess-mvpn- 2015年1月、bidir-ingress-replication-00。
[MVPN-XNET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-02, May 2015.
[MVPN-XNET] Rekhter、Y.、Ed。、Rosen、E.、Ed。、Aggarwal、R.、Cai、Y。、およびT. Morin、「BGP / IP MPLS VPNでのエクストラネットマルチキャスト」、作業中、draft-ietf-bess-mvpn-extranet-02、2015年5月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<http：//www.rfc -editor.org/info/rfc5331>。
[RFC6517] Morin, T., Ed., Niven-Jenkins, B., Ed., Kamite, Y., Zhang, R., Leymann, N., and N. Bitar, "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", RFC 6517, DOI 10.17487/RFC6517, February 2012, <http://www.rfc-editor.org/info/rfc6517>.
[RFC6517] Morin、T.、Ed。、Niven-Jenkins、B.、Ed。、Kamite、Y.、Zhang、R.、Leymann、N.、and N. Bitar、 "Mandatory Features in a Layer 3 Multicast BGP / MPLS VPN Solution」、RFC 6517、DOI 10.17487 / RFC6517、2012年2月、<http://www.rfc-editor.org/info/rfc6517>。
Acknowledgments
謝辞
The authors wish to thank Karthik Subramanian, Rajesh Sharma, and Apoorva Karan for their input. We also thank Yakov Rekhter for his valuable critique.
著者は、Karthik Subramanian、Rajesh Sharma、およびApoorva Karanに感謝の意を表します。また、ヤコフ・レクターの貴重な批評に感謝します。
Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review, probing questions, and useful suggestions.
Jeffrey（Zhaohui）Zhang氏の慎重なレビュー、詳細な質問、および有用な提案に感謝します。
Authors' Addresses
著者のアドレス
Eric C. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States
Eric C. Rosen Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: erosen@juniper.net
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands Cisco Systems、Inc. Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 United States
Y I Group CAI Microsoft 1065 LA av恩IDA mountain view、CA 94043アメリカ
Email: yiqunc@microsoft.com
Arjen Boers
アリエン・ボーアー
Email: arjen@boers.com