[要約] RFC 6513は、MPLS/BGP IP VPNsにおけるマルチキャストに関するガイドラインです。このRFCの目的は、マルチキャストトラフィックの効率的な配信とスケーラビリティを実現するための手法を提供することです。
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 6513 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Juniper Networks
February 2012
Multicast in MPLS/BGP IP VPNs
MPLS/BGP IP VPNのマルチキャスト
Abstract
概要
In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document.
BGP/MPLS IP VPN（仮想プライベートネットワーク）内のIPマルチキャストトラフィックのために、あるVPNサイトから別のVPNサイトに移動するには、VPNサービスプロバイダーが特別なプロトコルと手順を実装する必要があります。これらのプロトコルと手順は、このドキュメントで指定されています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc6513.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6513で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................5
2. Overview .......................................................5
2.1. Optimality vs. Scalability .................................5
2.1.1. Multicast Distribution Trees ........................7
2.1.2. Ingress Replication through Unicast Tunnels .........8
2.2. Multicast Routing Adjacencies ..............................8
2.3. MVPN Definition ............................................9
2.4. Auto-Discovery ............................................10
2.5. PE-PE Multicast Routing Information .......................11
2.6. PE-PE Multicast Data Transmission .........................11
2.7. Inter-AS MVPNs ............................................12
2.8. Optionally Eliminating Shared Tree State ..................13
3. Concepts and Framework .........................................13
3.1. PE-CE Multicast Routing ...................................13
3.2. P-Multicast Service Interfaces (PMSIs) ....................14
3.2.1. Inclusive and Selective PMSIs ......................15
3.2.2. P-Tunnels Instantiating PMSIs ......................16
3.3. Use of PMSIs for Carrying Multicast Data ..................18
3.4. PE-PE Transmission of C-Multicast Routing .................20
3.4.1. PIM Peering ........................................20
3.4.1.1. Full per-MVPN PIM Peering across
an MI-PMSI ................................20
3.4.1.2. Lightweight PIM Peering across an MI-PMSI .20
3.4.1.3. Unicasting of PIM C-Join/Prune Messages ...21
3.4.2. Using BGP to Carry C-Multicast Routing .............22
4. BGP-Based Auto-Discovery of MVPN Membership ....................22
5. PE-PE Transmission of C-Multicast Routing ......................25
5.1. Selecting the Upstream Multicast Hop (UMH) ................25
5.1.1. Eligible Routes for UMH Selection ..................26
5.1.2. Information Carried by Eligible UMH Routes .........26
5.1.3. Selecting the Upstream PE ..........................27
5.1.4. Selecting the Upstream Multicast Hop ...............29
5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI .........29
5.2.1. PIM C-Instance Control Packets .....................29
5.2.2. PIM C-Instance Reverse Path Forwarding
(RPF) Determination ................................30
5.3. Use of BGP for Carrying C-Multicast Routing ...............31
5.3.1. Sending BGP Updates ................................31
5.3.2. Explicit Tracking ..................................32
5.3.3. Withdrawing BGP Updates ............................32
5.3.4. BSR ................................................33
6. PMSI Instantiation .............................................33
6.1. Use of the Intra-AS I-PMSI A-D Route ......................34
6.1.1. Sending Intra-AS I-PMSI A-D Routes .................34
6.1.2. Receiving Intra-AS I-PMSI A-D Routes ...............35
6.2. When C-flows Are Specifically Bound to P-Tunnels ..........35
6.3. Aggregating Multiple MVPNs on a Single P-Tunnel ...........35
6.3.1. Aggregate Tree Leaf Discovery ......................36
6.3.2. Aggregation Methodology ............................36
6.3.3. Demultiplexing C-Multicast Traffic .................37
6.4. Considerations for Specific Tunnel Technologies ...........38
6.4.1. RSVP-TE P2MP LSPs ..................................39
6.4.2. PIM Trees ..........................................41
6.4.3. mLDP P2MP LSPs .....................................42
6.4.4. mLDP MP2MP LSPs ....................................42
6.4.5. Ingress Replication ................................42
7. Binding Specific C-Flows to Specific P-Tunnels .................44
7.1. General Considerations ....................................45
7.1.1. At the PE Transmitting the C-Flow on the P-Tunnel ..45
7.1.2. At the PE Receiving the C-flow from the P-Tunnel ...46
7.2. Optimizing Multicast Distribution via S-PMSIs .............48
7.3. Announcing the Presence of Unsolicited Flooded Data .......49
7.4. Protocols for Binding C-Flows to P-Tunnels ................50
7.4.1. Using BGP S-PMSI A-D Routes ........................50
7.4.1.1. Advertising C-Flow Binding to P-Tunnel ....50
7.4.1.2. Explicit Tracking .........................51
7.4.2. UDP-Based Protocol .................................52
7.4.2.1. Advertising C-Flow Binding to P-Tunnel ....52
7.4.2.2. Packet Formats and Constants ..............53
7.4.3. Aggregation ........................................55
8. Inter-AS Procedures ............................................55
8.1. Non-Segmented Inter-AS P-Tunnels ..........................56
8.1.1. Inter-AS MVPN Auto-Discovery .......................56
8.1.2. Inter-AS MVPN Routing Information Exchange .........56
8.1.3. Inter-AS P-Tunnels .................................57
8.1.3.1. PIM-Based Inter-AS P-Multicast Trees ......57
8.1.3.2. The PIM MVPN Join Attribute ...............58
8.1.3.2.1. Definition .....................58
8.1.3.2.2. Usage ..........................59
8.2. Segmented Inter-AS P-Tunnels ..............................60
9. Preventing Duplication of Multicast Data Packets ...............60
9.1. Methods for Ensuring Non-Duplication ......................61
9.1.1. Discarding Packets from Wrong PE ...................62
9.1.2. Single Forwarder Selection .........................63
9.1.3. Native PIM Methods .................................63
9.2. Multihomed C-S or C-RP ....................................63
9.3. Switching from the C-RP Tree to the C-S Tree ..............63
9.3.1. How Duplicates Can Occur ...........................63
9.3.2. Solution Using Source Active A-D Routes ............65
10. Eliminating PE-PE Distribution of (C-*,C-G) State .............67
10.1. Co-Locating C-RPs on a PE ................................68
10.1.1. Initial Configuration .............................68
10.1.2. Anycast RP Based on Propagating Active Sources ....68
10.1.2.1. Receiver(s) within a Site ................69
10.1.2.2. Source within a Site .....................69
10.1.2.3. Receiver Switching from Shared to
Source Tree ..............................69
10.2. Using MSDP between a PE and a Local C-RP .................69
11. Support for PIM-BIDIR C-Groups ................................71
11.1. The VPN Backbone Becomes the RPL .........................72
11.1.1. Control Plane .....................................72
11.1.2. Data Plane ........................................73
11.2. Partitioned Sets of PEs ..................................73
11.2.1. Partitions ........................................73
11.2.2. Using PE Distinguisher Labels .....................74
11.2.3. Partial Mesh of MP2MP P-Tunnels ...................75
12. Encapsulations ................................................75
12.1. Encapsulations for Single PMSI per P-Tunnel ..............75
12.1.1. Encapsulation in GRE ..............................75
12.1.2. Encapsulation in IP ...............................76
12.1.3. Encapsulation in MPLS .............................77
12.2. Encapsulations for Multiple PMSIs per P-Tunnel ...........78
12.2.1. Encapsulation in GRE ..............................78
12.2.2. Encapsulation in IP ...............................78
12.3. Encapsulations Identifying a Distinguished PE ............78
12.3.1. For MP2MP LSP P-Tunnels ...........................78
12.3.2. For Support of PIM-BIDIR C-Groups .................79
12.4. General Considerations for IP and GRE Encapsulations .....79
12.4.1. MTU (Maximum Transmission Unit) ...................79
12.4.2. TTL (Time to Live) ................................80
12.4.3. Avoiding Conflict with Internet Multicast .........80
12.5. Differentiated Services ..................................81
13. Security Considerations .......................................81
14. IANA Considerations ...........................................83
15. Acknowledgments ...............................................83
16. References ....................................................84
16.1. Normative References .....................................84
16.2. Informative References ...................................85
[RFC4364] specifies the set of procedures that a Service Provider (SP) must implement in order to provide a particular kind of VPN service ("BGP/MPLS IP VPN") for its customers. The service described therein allows IP unicast packets to travel from one customer site to another, but it does not provide a way for IP multicast traffic to travel from one customer site to another.
[RFC4364]は、顧客に特定の種類のVPNサービス（「BGP/MPLS IP VPN」）を提供するために、サービスプロバイダー（SP）が実装しなければならない一連の手順を指定します。そこに記載されているサービスでは、IPユニキャストパケットがある顧客サイトから別の顧客サイトに移動することができますが、IPマルチキャストトラフィックがある顧客サイトから別のサイトに移動する方法は提供されません。
This document extends the service defined in [RFC4364] so that it also includes the capability of handling IP multicast traffic. This requires a number of different protocols to work together. The document provides a framework describing how the various protocols fit together, and it also provides a detailed specification of some of the protocols. The detailed specification of some of the other protocols is found in preexisting documents or in companion documents.
このドキュメントは、[RFC4364]で定義されているサービスを拡張して、IPマルチキャストトラフィックの処理機能も含めるようにします。これには、協力するにはさまざまなプロトコルが必要です。このドキュメントは、さまざまなプロトコルがどのように適合するかを説明するフレームワークを提供し、一部のプロトコルの詳細な仕様も提供します。他のいくつかのプロトコルの詳細な仕様は、既存のドキュメントまたはコンパニオンドキュメントにあります。
A BGP/MPLS IP VPN service that supports multicast is known as a "Multicast VPN" or "MVPN".
マルチキャストをサポートするBGP/MPLS IP VPNサービスは、「マルチキャストVPN」または「MVPN」として知られています。
Both this document and its companion document [MVPN-BGP] discuss the use of various BGP messages and procedures to provide MVPN support. While every effort has been made to ensure that the two documents are consistent with each other, it is possible that discrepancies have crept in. In the event of any conflict or other discrepancy with respect to the use of BGP in support of MVPN service, [MVPN-BGP] is to be considered to be the authoritative document.
このドキュメントとそのコンパニオンドキュメント[MVPN-BGP]の両方が、MVPNサポートを提供するために、さまざまなBGPメッセージと手順の使用について説明します。2つのドキュメントが互いに一致するようにするためにあらゆる努力が払われていますが、MVPNサービスをサポートするBGPの使用に関して紛争またはその他の矛盾がある場合、矛盾がcrep延している可能性があります。MVPN-BGP]は、権威ある文書と見なされます。
Throughout this document, we will use the term "VPN-IP route" to mean a route that is either in the VPN-IPv4 address family [RFC4364] or in the VPN-IPv6 address family [RFC4659].
このドキュメント全体で、「VPN-IPルート」という用語を使用して、VPN-IPV4アドレスファミリー[RFC4364]またはVPN-IPV6アドレスファミリー[RFC4659]のいずれかのルートを意味します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is achieved without the need to keep any per-VPN state in the core of the SP's network (the "P routers"). Routing information from a particular VPN is maintained only by the Provider Edge routers (the "PE routers", or "PEs") that attach directly to sites of that VPN. Customer data travels through the P routers in tunnels from one PE to another (usually MPLS Label Switched Paths, LSPs), so to support the
「BGP/MPLS IP VPN」[RFC4364]では、VPNパケットのユニキャストルーティングは、SPのネットワーク（「Pルーター」）のコアにVPNごとの状態を維持する必要なく達成されます。特定のVPNからのルーティング情報は、そのVPNのサイトに直接接続するプロバイダーエッジルーター（「PEルーター」または「PES」）によってのみ維持されます。顧客データは、あるPEから別のPEにトンネルのPルーターを通過します（通常、MPLSラベルスイッチパス、LSP）。
VPN service the P routers only need to have routes to the PE routers. The PE-to-PE routing is optimal, but the amount of associated state in the P routers depends only on the number of PEs, not on the number of VPNs.
VPNサービスPルーターには、PEルーターへのルートのみが必要です。PE-ToPEルーティングは最適ですが、Pルーターの関連状態の量は、VPNの数ではなく、PEの数のみに依存します。
However, in order to provide optimal multicast routing for a particular multicast flow, the P routers through which that flow travels have to hold state that is specific to that flow. A multicast flow is identified by the (source, group) tuple where the source is the IP address of the sender and the group is the IP multicast group address of the destination. Scalability would be poor if the amount of state in the P routers were proportional to the number of multicast flows in the VPNs. Therefore, when supporting multicast service for a BGP/MPLS IP VPN, the optimality of the multicast routing must be traded off against the scalability of the P routers. We explain this below in more detail.
ただし、特定のマルチキャストフローに最適なマルチキャストルーティングを提供するためには、その流れがその流れに固有の状態を保持する必要があるPルーター。マルチキャストフローは、ソースが送信者のIPアドレスであり、グループが宛先のIPマルチキャストグループアドレスである（ソース、グループ）タプルによって識別されます。Pルーターの状態の量がVPNのマルチキャストフローの数に比例した場合、スケーラビリティは低くなります。したがって、BGP/MPLS IP VPNのマルチキャストサービスをサポートする場合、マルチキャストルーティングの最適性は、Pルーターのスケーラビリティに対してトレードオフする必要があります。これについては、詳細に説明します。
If a particular VPN is transmitting "native" multicast traffic over the backbone, we refer to it as an "MVPN". By "native" multicast traffic, we mean packets that a Customer Edge router (a "CE router" or "CE") sends to a PE, such that the IP destination address of the packets is a multicast group address, the packets are multicast control packets addressed to the PE router itself, or the packets are IP multicast data packets encapsulated in MPLS.
特定のVPNがバックボーン上で「ネイティブ」マルチキャストトラフィックを送信している場合、「MVPN」と呼びます。「ネイティブ」マルチキャストトラフィックとは、顧客エッジルーター（「CEルーター」または「CE」）がPEに送信するパケットを意味するため、パケットのIP宛先アドレスがマルチキャストグループアドレスであり、パケットはマルチキャストです。PEルーター自体にアドレス指定されたコントロールパケット、またはパケットは、MPLSにカプセル化されたIPマルチキャストデータパケットです。
We say that the backbone multicast routing for a particular multicast group in a particular VPN is "optimal" if and only if all of the following conditions hold:
特定のVPNの特定のマルチキャストグループのバックボーンマルチキャストルーティングは、次のすべての条件が保持されている場合にのみ「最適」であると言います。
- When a PE router receives a multicast data packet of that group from a CE router, it transmits the packet in such a way that the packet is received by every other PE router that is on the path to a receiver of that group;
- PEルーターがCEルーターからそのグループのマルチキャストデータパケットを受信すると、パケットがそのグループの受信機へのパス上にある他のすべてのPEルーターによってパケットが受信されるようにパケットを送信します。
- The packet is not received by any other PEs;
- パケットは他のPESによって受信されません。
- While in the backbone, no more than one copy of the packet ever traverses any link.
- バックボーンにいる間、パケットのコピーが1つしかありません。これはリンクを通過します。
- While in the backbone, if bandwidth usage is to be optimized, the packet traverses minimum cost trees rather than shortest path trees.
- バックボーンでは、帯域幅の使用が最適化される場合、パケットは最短のパスツリーではなく最小コストツリーを通過します。
Optimal routing for a particular multicast group requires that the backbone maintain one or more source trees that are specific to that flow. Each such tree requires that state be maintained in all the P routers that are in the tree.
特定のマルチキャストグループに最適なルーティングでは、バックボーンがその流れに固有の1つ以上のソースツリーを維持する必要があります。そのような各ツリーは、ツリー内にあるすべてのPルーターで状態を維持する必要があります。
Potentially, this would require an unbounded amount of state in the P routers, since the SP has no control of the number of multicast groups in the VPNs that it supports. The SP also doesn't have any control over the number of transmitters in each group, nor over the distribution of the receivers.
潜在的に、これには、SPがサポートするVPNのマルチキャストグループの数を制御できないため、Pルーターには無限の状態が必要になります。SPは、各グループの送信機の数も、受信機の分布も制御できません。
The procedures defined in this document allow an SP to provide multicast VPN service, without requiring the amount of state maintained by the P routers to be proportional to the number of multicast data flows in the VPNs. The amount of state is traded off against the optimality of the multicast routing. Enough flexibility is provided so that a given SP can make his own trade-offs between scalability and optimality. An SP can even allow some multicast groups in some VPNs to receive optimal routing, while others do not. Of course, the cost of this flexibility is an increase in the number of options provided by the protocols.
このドキュメントで定義されている手順により、SPは、VPNのマルチキャストデータフローの数に比例するPルーターによって維持される状態の量を要求することなく、マルチキャストVPNサービスを提供することができます。州の量は、マルチキャストルーティングの最適性に対してトレードオフされます。特定のSPがスケーラビリティと最適性の間に独自のトレードオフを行うことができるように、十分な柔軟性が提供されます。SPは、一部のVPNの一部のマルチキャストグループが最適なルーティングを受信できるようにすることさえできますが、他のSPは最適なルーティングを受け取ることもできます。もちろん、この柔軟性のコストは、プロトコルによって提供されるオプションの数の増加です。
The basic technique for providing scalability is to aggregate a number of customer multicast flows onto a single multicast distribution tree through the P routers. A number of aggregation methods are supported.
スケーラビリティを提供するための基本的な手法は、Pルーターを介して多くの顧客マルチキャストフローを単一のマルチキャスト配布ツリーに集約することです。多くの集約方法がサポートされています。
The procedures defined in this document also accommodate the SP that does not want to build multicast distribution trees in his backbone at all; the ingress PE can replicate each multicast data packet and then unicast each replica through a tunnel to each egress PE that needs to receive the data.
このドキュメントで定義されている手順は、バックボーンにマルチキャスト分布ツリーをまったく構築したくないSPにも対応しています。Ingress PEは、各マルチキャストデータパケットを複製し、各レプリカをトンネルを介してデータを受信する必要がある各出力PEにユニカストできます。
This document supports the use of a single multicast distribution tree in the backbone to carry all the multicast traffic from a specified set of one or more MVPNs. Such a tree is referred to as an "Inclusive Tree". An Inclusive Tree that carries the traffic of more than one MVPN is an "Aggregate Inclusive Tree". An Inclusive Tree contains, as its members, all the PEs that attach to any of the MVPNs using the tree.
このドキュメントは、バックボーンに単一のマルチキャスト分布ツリーを使用して、指定された1つ以上のMVPNのすべてのマルチキャストトラフィックを運ぶことをサポートしています。そのような木は「包括的な木」と呼ばれます。複数のMVPNのトラフィックを運ぶ包括的なツリーは、「集計包括的なツリー」です。包括的なツリーには、そのメンバーとして、ツリーを使用してMVPNのいずれかに付着するすべてのPEが含まれています。
With this option, even if each tree supports only one MVPN, the upper bound on the amount of state maintained by the P routers is proportional to the number of VPNs supported rather than to the number of multicast flows in those VPNs. If the trees are unidirectional, it would be more accurate to say that the state is proportional to the product of the number of VPNs and the average number of PEs per VPN. The amount of state maintained by the P routers can be further reduced by aggregating more MVPNs onto a single tree. If each such tree supports a set of MVPNs, (call it an "MVPN aggregation set"), the state maintained by the P routers is
このオプションを使用すると、各ツリーが1つのMVPNのみをサポートしていても、Pルーターによって維持される状態の量の上限は、それらのVPNのマルチキャストフローの数ではなく、サポートされるVPNの数に比例します。ツリーが単方向である場合、状態はVPNの数とVPNあたりのPESの平均数の積に比例していると言う方が正確です。Pルーターによって維持される状態の量は、より多くのMVPNを単一のツリーに集約することでさらに減らすことができます。そのような各ツリーがMVPNのセットをサポートしている場合（「MVPN集約セット」と呼ぶ）、Pルーターによって維持される状態は
proportional to the product of the number of MVPN aggregation sets and the average number of PEs per MVPN. Thus, the state does not grow linearly with the number of MVPNs.
MVPN凝集セットの数とMVPNあたりのPESの平均数の積に比例します。したがって、状態はMVPNの数で直線的に成長しません。
However, as data from many multicast groups is aggregated together onto a single Inclusive Tree, it is likely that some PEs will receive multicast data for which they have no need, i.e., some degree of optimality has been sacrificed.
ただし、多くのマルチキャストグループのデータが単一の包括的なツリーに集約されているため、一部のPEは必要としないマルチキャストデータを受け取る可能性があります。つまり、ある程度の最適性が犠牲になっています。
This document also provides procedures that enable a single multicast distribution tree in the backbone to be used to carry traffic belonging only to a specified set of one or more multicast groups, from one or more MVPNs. Such a tree is referred to as a "Selective Tree" and more specifically as an "Aggregate Selective Tree" when the multicast groups belong to different MVPNs. By default, traffic from most multicast groups could be carried by an Inclusive Tree, while traffic from, e.g., high bandwidth groups could be carried in one of the Selective Trees. When setting up the Selective Trees, one should include only those PEs that need to receive multicast data from one or more of the groups assigned to the tree. This provides more optimal routing than can be obtained by using only Inclusive Trees, though it requires additional state in the P routers.
このドキュメントは、バックボーン内の単一のマルチキャスト配布ツリーを、1つ以上のMVPNからの1つまたは複数のマルチキャストグループの指定されたセットのみに属するトラフィックを運ぶために使用できるようにする手順も提供します。このようなツリーは、マルチキャストグループが異なるMVPNに属している場合、「選択的ツリー」と呼ばれ、より具体的には「集計選択ツリー」と呼ばれます。デフォルトでは、ほとんどのマルチキャストグループからのトラフィックは包括的なツリーによって運ばれますが、たとえば、高帯域幅グループからのトラフィックは、選択的なツリーの1つで運ばれます。選択的なツリーをセットアップするときは、ツリーに割り当てられた1つ以上のグループからマルチキャストデータを受信する必要があるPEのみを含める必要があります。これにより、包括的ツリーのみを使用して取得できるよりも最適なルーティングが提供されますが、Pルーターには追加の状態が必要です。
This document also provides procedures for carrying MVPN data traffic through unicast tunnels from the ingress PE to each of the egress PEs. The ingress PE replicates the multicast data packet received from a CE and sends it to each of the egress PEs using the unicast tunnels. This requires no multicast routing state in the P routers at all, but it puts the entire replication load on the ingress PE router and makes no attempt to optimize the multicast routing.
このドキュメントは、侵入PEから各出口PEにユニキャストトンネルを介してMVPNデータトラフィックを運ぶ手順も提供します。Ingress PEは、CEから受信したマルチキャストデータパケットを複製し、ユニキャストトンネルを使用して各出力PEに送信します。これには、Pルーターのマルチキャストルーティング状態はまったく必要ありませんが、Ingress PEルーターに完全な複製負荷をかけ、マルチキャストルーティングを最適化しようとはしません。
In BGP/MPLS IP VPNs [RFC4364], each CE (Customer Edge) router is a unicast routing adjacency of a PE router, but CE routers at different sites do not become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing -- a CE router becomes a multicast routing adjacency of a PE router, but CE routers at different sites do not become multicast routing adjacencies of each other.
BGP/MPLS IP VPNS [RFC4364]では、各CE（顧客エッジ）ルーターはPEルーターのユニキャストルーティング隣接性ですが、さまざまなサイトのCEルーターは互いにユニキャストルーティングに隣接するものではありません。この重要な特性は、マルチキャストルーティングのために保持されます。CEルーターは、PEルーターのマルチキャストルーティングの隣接になりますが、さまざまなサイトのCEルーターは互いのマルチキャストルーティング隣接になりません。
We will use the term "C-tree" to refer to a multicast distribution tree whose nodes include CE routers. (See Section 3.1 for further explication of this terminology.)
「C-Tree」という用語を使用して、ノードがCEルーターを含むマルチキャスト分布ツリーを参照します。（この用語のさらなる説明については、セクション3.1を参照してください。）
The multicast routing protocol on the PE-CE link is presumed to be PIM (Protocol Independent Multicast) [PIM-SM]. Both the ASM (Any-Source Multicast) and the SSM (Source-Specific Multicast) service models are supported. Thus, both shared C-trees and source-specific C-trees are supported. Shared C-trees may be unidirectional or bidirectional; in the latter case, the multicast routing protocol is presumed to be the BIDIR-PIM [BIDIR-PIM] "variant" of PIM-SM. A CE router exchanges "ordinary" PIM control messages with the PE router to which it is attached.
PE-CEリンクのマルチキャストルーティングプロトコルは、PIM（Protocol Independent Multicast）[PIM-SM]であると推定されます。ASM（Any-Source Multicast）とSSM（ソース固有のマルチキャスト）サービスモデルの両方がサポートされています。したがって、共有Cツリーとソース固有のCツリーの両方がサポートされています。共有Cツリーは、一方向または双方向である場合があります。後者の場合、マルチキャストルーティングプロトコルは、PIM-SMのBidir-PIM [Bidir-PIM]「バリアント」であると推定されます。CEルーターは、接続されているPEルーターと「通常の」PIM制御メッセージを交換します。
Support for PIM-DM (Dense Mode) is outside the scope of this document.
PIM-DMのサポート（密度モード）は、このドキュメントの範囲外です。
The PEs attaching to a particular MVPN then have to exchange the multicast routing information with each other. Two basic methods for doing this are defined: (1) PE-PE PIM and (2) BGP. In the former case, the PEs need to be multicast routing adjacencies of each other. In the latter case, they do not. For example, each PE may be a BGP adjacency of a route reflector (RR) and not of any other PEs.
特定のMVPNに接続するPESは、マルチキャストルーティング情報を互いに交換する必要があります。これを行うための2つの基本的な方法が定義されています。（1）PE-PE PIMと（2）BGP。前者の場合、PESは互いに隣接するマルチキャストルーティングである必要があります。後者の場合、そうではありません。たとえば、各PEは、他のPESではなく、ルートリフレクター（RR）のBGP隣接性である場合があります。
In order to support the "Carrier's Carrier" model of [RFC4364], mLDP (Label Distribution Protocol Extensions for Multipoint Label Switched Paths) [MLDP] may also be supported on the PE-CE interface. The use of mLDP on the PE-CE interface is described in [MVPN-BGP]. The use of BGP on the PE-CE interface is not within the scope of this document.
[RFC4364]の「キャリアキャリア」モデルをサポートするために、MLDP（マルチポイントラベルスイッチ付きパスのラベル分布プロトコル拡張）[MLDP]もPE-CEインターフェイスでサポートされる場合があります。PE-CEインターフェイスでのMLDPの使用は、[MVPN-BGP]で説明されています。PE-CEインターフェイスでのBGPの使用は、このドキュメントの範囲内ではありません。
An MVPN is defined by two sets of sites: the Sender Sites set and the Receiver Sites set, with the following properties:
MVPNは、2つのセットのサイトで定義されます。送信者サイトセットとレシーバーサイトが設定され、次のプロパティがあります。
- Hosts within the Sender Sites set could originate multicast traffic for receivers in the Receiver Sites set.
- Senderサイトセット内のホストは、受信機セットのレシーバーのマルチキャストトラフィックを発信する可能性があります。
- Receivers not in the Receiver Sites set should not be able to receive this traffic.
- セットされたレシーバーサイトにないレシーバーは、このトラフィックを受信できないはずです。
- Hosts within the Receiver Sites set could receive multicast traffic originated by any host in the Sender Sites set.
- セットセットのレシーバーサイト内のホストは、セットセットの任意のホストが発信するマルチキャストトラフィックを受信できます。
- Hosts within the Receiver Sites set should not be able to receive multicast traffic originated by any host that is not in the Sender Sites set.
- セットされたレシーバーサイト内のホストは、セットセットにないホストが発信するマルチキャストトラフィックを受け取ることができないはずです。
A site could be both in the Sender Sites set and Receiver Sites set, which implies that hosts within such a site could both originate and receive multicast traffic. An extreme case is when the Sender Sites set is the same as the Receiver Sites set, in which case all sites could originate and receive multicast traffic from each other.
サイトは、Senderサイトセットとレシーバーサイトセットの両方にあります。これは、そのようなサイト内のホストがマルチキャストトラフィックの発生と受信の両方を受け取る可能性があることを意味します。極端なケースは、Senderサイトの設定がセットされたレシーバーサイトと同じである場合です。その場合、すべてのサイトが互いにマルチキャストトラフィックを発信して受信することができます。
Sites within a given MVPN may be either within the same organization or in different organizations, which implies that an MVPN can be either an Intranet or an Extranet.
特定のMVPN内のサイトは、同じ組織内または異なる組織内のいずれかである場合があります。これは、MVPNがイントラネットまたはエクストラネットのいずれかであることを意味します。
A given site may be in more than one MVPN, which implies that MVPNs may overlap.
特定のサイトは複数のMVPNである可能性があり、これはMVPNが重複する可能性があることを意味します。
Not all sites of a given MVPN have to be connected to the same service provider, which implies that an MVPN can span multiple service providers.
特定のMVPNのすべてのサイトを同じサービスプロバイダーに接続する必要があるわけではありません。これは、MVPNが複数のサービスプロバイダーにまたがることができることを意味します。
Another way to look at MVPN is to say that an MVPN is defined by a set of administrative policies. Such policies determine both the Sender Sites set and Receiver Sites set. Such policies are established by MVPN customers, but implemented/realized by MVPN Service Providers using the existing BGP/MPLS VPN mechanisms, such as Route Targets (RTs), with extensions, as necessary.
MVPNを見る別の方法は、MVPNが一連の管理ポリシーによって定義されていると言うことです。このようなポリシーは、設定されている送信者サイトとセットされたレシーバーサイトの両方を決定します。このようなポリシーはMVPNの顧客によって確立されますが、必要に応じて拡張機能を使用して、ルートターゲット（RTS）などの既存のBGP/MPLS VPNメカニズムを使用してMVPNサービスプロバイダーによって実装/実現されます。
In order for the PE routers attaching to a given MVPN to exchange MVPN control information with each other, each one needs to discover all the other PEs that attach to the same MVPN. (Strictly speaking, a PE in the Receiver Sites set need only discover the other PEs in the Sender Sites set, and a PE in the Sender Sites set need only discover the other PEs in the Receiver Sites set.) This is referred to as "MVPN Auto-Discovery".
特定のMVPNに取り付けてMVPN制御情報を互いに交換するために、それぞれが同じMVPNに付着する他のすべてのPEを発見する必要があります。（厳密に言えば、受信者サイトのPEは、セットセットの他のPEを発見する必要があり、送信サイトセットのPEは、セットされたレシーバーサイトの他のPEを発見するだけです。）MVPNオートディスコーブリー "。
This document discusses two ways of providing MVPN auto-discovery:
このドキュメントでは、MVPNの自動発見を提供する2つの方法について説明します。
- BGP can be used for discovering and maintaining MVPN membership. The PE routers advertise their MVPN membership to other PE routers using BGP. A PE is considered to be a "member" of a particular MVPN if it contains a VRF (Virtual Routing and Forwarding table, see [RFC4364]) that is configured to contain the multicast routing information of that MVPN. This auto-discovery option does not make any assumptions about the methods used for transmitting MVPN multicast data packets through the backbone.
- BGPは、MVPNメンバーシップの発見と維持に使用できます。PEルーターは、BGPを使用してMVPNメンバーシップを他のPEルーターに宣伝しています。PEは、そのMVPNのマルチキャストルーティング情報を含むように構成されているVRF（仮想ルーティングおよび転送テーブル、[RFC4364]を参照）を含む場合、特定のMVPNの「メンバー」と見なされます。この自動発見オプションでは、バックボーンを介してMVPNマルチキャストデータパケットを送信するために使用される方法について仮定しません。
- If it is known that the PE-PE multicast control packets (i.e., PIM packets) of a particular MVPN are to be transmitted through a non-aggregated Inclusive Tree supporting the ASM service model (e.g., through a tree that is created by non-SSM PIM-SM or by BIDIR-PIM), and if the PEs attaching to that MVPN are configured with the group address corresponding to that tree, then the PEs can auto-discover each other simply by joining the tree and then multicasting PIM Hellos over the tree.
- 特定のMVPNのPE-PEマルチキャスト制御パケット（すなわち、PIMパケット）は、ASMサービスモデルをサポートする非凝集包括的なツリーを介して送信されることがわかっている場合（例えば、非非によって作成されたツリーを介して送信されます。ssm pim-smまたはbydir-pim）、およびそのMVPNに付着するPEがそのツリーに対応するグループアドレスで構成されている場合、PESは単にツリーに参加して、PIM Hellosをマルチリキャストするだけで互いに互いに発見できます。木。
The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain, at most, one BGP peering with every other PE in the network. This peering is used to exchange VPN routing information. The use of route reflectors further reduces the number of BGP adjacencies maintained by a PE to exchange VPN routing information with other PEs. This document describes various options for exchanging MVPN control information between PE routers based on the use of PIM or BGP. These options have different overheads with respect to the number of routing adjacencies that a PE router needs to maintain to exchange MVPN control information with other PE routers. Some of these options allow the retention of the unicast BGP/MPLS VPN model letting a PE maintain, at most, one BGP routing adjacency with other PE routers to exchange MVPN control information. BGP also provides reliable transport and uses incremental updates. Another option is the use of the currently existing "soft state" PIM standard [PIM-SM] that uses periodic complete updates.
BGP/MPLS IP VPN [RFC4364]仕様では、ネットワーク内の他のすべてのPEと最大1つのBGPがピアリングするためにPEを維持する必要があります。このピアリングは、VPNルーティング情報を交換するために使用されます。ルートリフレクターを使用すると、PEによって維持されるBGP隣接の数がさらに減少し、VPNルーティング情報を他のPEと交換します。このドキュメントでは、PIMまたはBGPの使用に基づいて、PEルーター間でMVPN制御情報を交換するためのさまざまなオプションについて説明します。これらのオプションは、PEルーターが他のPEルーターとMVPN制御情報を交換するために維持する必要があるルーティング隣接の数に関して異なるオーバーヘッドを持っています。これらのオプションの一部により、Unicast BGP/MPLS VPNモデルの保持により、PEを他のPEルーターと隣接する1つのBGPルーティングを維持して、MVPN制御情報を交換できます。 BGPは、信頼できる輸送も提供し、増分更新を使用します。別のオプションは、定期的な完全な更新を使用する現在存在する「ソフトステート」PIM標準[PIM-SM]の使用です。
Like [RFC4364], this document decouples the procedures for exchanging routing information from the procedures for transmitting data traffic. Hence, a variety of transport technologies may be used in the backbone. For Inclusive Trees, these transport technologies include unicast PE-PE tunnels, using encapsulation in MPLS, IP, or GRE (Generic Routing Encapsulation), multicast distribution trees created by PIM (either unidirectional in the SSM or ASM service models or bidirectional) using IP/GRE encapsulation, point-to-multipoint LSPs created by RSVP - Traffic Engineering (RSVP-TE) or mLDP, and multipoint-to-multipoint LSPs created by mLDP.
[RFC4364]と同様に、このドキュメントは、データトラフィックを送信する手順からルーティング情報を交換する手順を切り離します。したがって、バックボーンではさまざまな輸送技術を使用できます。包括的なツリーの場合、これらの輸送技術には、MPLS、IP、またはGRE（一般的なルーティングカプセル化）のカプセル化を使用したユニキャストPE-PEトンネル、PIMによって作成されたマルチキャスト分布ツリー（SSMの単方向またはASMサービスモデルまたは双方向）を使用してIPを使用して含まれます。/GREカプセル化、RSVPによって作成されたポイントツーマルチポイントLSP-トラフィックエンジニアリング（RSVP-TE）またはMLDP、およびMLDPが作成したマルプポイントツーマルチポイントLSP。
In order to aggregate traffic from multiple MVPNs onto a single multicast distribution tree, it is necessary to have a mechanism to enable the egresses of the tree to demultiplex the multicast traffic received over the tree and to associate each received packet with a particular MVPN. This document specifies a mechanism whereby upstream label assignment [MPLS-UPSTREAM-LABEL] is used by the root of the tree to assign a label to each flow. This label is used by
複数のMVPNSから単一のマルチキャスト配布ツリーにトラフィックを集約するには、ツリーの出口がツリー上で受け取ったマルチキャストトラフィックを非難し、受信した各パケットを特定のMVPNに関連付けるメカニズムを持つ必要があります。このドキュメントは、上流のラベル割り当て[Mpls-upstream-Label]がツリーのルートによって使用され、各フローにラベルを割り当てるメカニズムを指定します。このラベルはによって使用されます
the receivers to perform the demultiplexing. This document also describes procedures based on BGP that are used by the root of an Aggregate Tree to advertise the Inclusive and/or Selective binding and the demultiplexing information to the leaves of the tree.
再退屈を実行するレシーバー。また、このドキュメントでは、総合的なバインディングおよび/または選択的バインディングと、ツリーの葉への脱臼情報を宣伝するために、骨材のルートによって使用されるBGPに基づく手順についても説明します。
This document also describes the data plane encapsulations for supporting the various SP multicast transport options.
このドキュメントでは、さまざまなSPマルチキャスト輸送オプションをサポートするためのデータプレーンのカプセルについても説明しています。
The specification for aggregating traffic of multiple MVPNs onto a single multipoint-to-multipoint LSP or onto a single bidirectional multicast distribution tree is outside the scope of this document.
複数のMVPNのトラフィックを単一のマルチポイントからマルチポイントLSPまたは単一の双方向マルチキャスト分布ツリーに集約するための仕様は、このドキュメントの範囲外です。
The specifications for using, as Selective Trees, multicast distribution trees that support the ASM service model are outside the scope of this document. The specification for using multipoint-to-multipoint LSPs as Selective Trees is outside the scope of this document.
ASMサービスモデルをサポートする選択的なツリーとして、選択的なツリーを使用するための仕様は、このドキュメントの範囲外です。Multipoint-to-MultiPoint LSPを選択的なツリーとして使用するための仕様は、このドキュメントの範囲外です。
This document assumes that when SP multicast trees are used, traffic for a particular multicast group is transmitted by a particular PE on only one SP multicast tree. The use of multiple SP multicast trees for transmitting traffic belonging to a particular multicast group is outside the scope of this document.
このドキュメントは、SPマルチキャストツリーを使用すると、特定のマルチキャストグループのトラフィックが特定のPEによって1つのSPマルチキャストツリーのみで送信されることを前提としています。特定のマルチキャストグループに属するトラフィックを送信するための複数のSPマルチキャストツリーの使用は、このドキュメントの範囲外です。
[RFC4364] describes different options for supporting BGP/MPLS IP unicast VPNs whose provider backbones contain more than one Autonomous System (AS). These are known as "inter-AS VPNs". In an inter-AS VPN, the ASes may belong to the same provider or to different providers. This document describes how inter-AS MVPNs can be supported for each of the unicast BGP/MPLS VPN inter-AS options. This document also specifies a model where inter-AS MVPN service can be offered without requiring a single SP multicast tree to span multiple ASes. In this model, an inter-AS multicast tree consists of a number of "segments", one per AS, that are stitched together at AS boundary points. These are known as "segmented inter-AS trees". Each segment of a segmented inter-AS tree may use a different multicast transport technology.
[RFC4364]は、プロバイダーのバックボーンが複数の自律システム（AS）を含むBGP/MPLS IPユニキャストVPNをサポートするためのさまざまなオプションを説明しています。これらは「inter-as vpns」として知られています。AS Inter-AS VPNでは、ASEは同じプロバイダーまたは異なるプロバイダーに属している場合があります。このドキュメントでは、Unicast BGP/MPLS VPN Inter-ASオプションのそれぞれでMVPNをサポートする方法について説明します。このドキュメントでは、複数のASESに及ぶ単一のSPマルチキャストツリーを必要とせずに、MVPN間のサービスを提供できるモデルも指定しています。このモデルでは、AS間のマルチキャストツリーは、境界点として一緒に縫い付けられている多くの「セグメント」で構成されています。これらは「セグメント化された樹木」として知られています。セグメント化されたASツリーの各セグメントは、異なるマルチキャスト輸送技術を使用する場合があります。
It is also possible to support inter-AS MVPNs with non-segmented source trees that extend across AS boundaries.
また、境界として広がるセグメント化されていないソースツリーでMVPNをサポートすることも可能です。
This document also discusses some options and protocol extensions that can be used to eliminate the need for the PE routers to distribute to each other the (*,G) and (*,G,rpt) states that occur when the VPNs are creating unidirectional C-trees to support the ASM service model.
このドキュメントでは、PEルーターが互いに分布する必要性を排除するために使用できるいくつかのオプションとプロトコル拡張機能についても説明します（*、g）、および（*、g、rpt）は、VPNが単方向cを作成しているときに発生する状態です。-ASMサービスモデルをサポートするためのツリー。
Support of multicast in BGP/MPLS IP VPNs is modeled closely after the support of unicast in BGP/MPLS IP VPNs. That is, a multicast routing protocol will be run on the PE-CE interfaces, such that PE and CE are multicast routing adjacencies on that interface. CEs at different sites do not become multicast routing adjacencies of each other.
BGP/MPLS IP VPNでのマルチキャストのサポートは、BGP/MPLS IP VPNSのユニキャストのサポート後に密接にモデル化されています。つまり、PE-CEインターフェイスでマルチキャストルーティングプロトコルが実行されるため、PEとCEはそのインターフェイスのマルチキャストルーティング隣接です。さまざまなサイトのCESは、互いに隣接するマルチキャストルーティングにはなりません。
If a PE attaches to n VPNs for which multicast support is provided (i.e., to n "MVPNs"), the PE will run n independent instances of a multicast routing protocol. We will refer to these multicast routing instances as "VPN-specific multicast routing instances", or more briefly as "multicast C-instances". The notion of a "VRF" (VPN Routing and Forwarding Table), defined in [RFC4364], is extended to include multicast routing entries as well as unicast routing entries. Each multicast routing entry is thus associated with a particular VRF.
PEがマルチキャストサポートが提供されるn VPN（つまり、n "mvpns"）に付着する場合、PEはマルチキャストルーティングプロトコルのn独立インスタンスを実行します。これらのマルチキャストルーティングインスタンスを「VPN固有のマルチキャストルーティングインスタンス」と呼び、より簡単に「マルチキャストCインスタンス」と呼びます。[RFC4364]で定義されている「VRF」（VPNルーティングと転送テーブル）の概念は、マルチキャストルーティングエントリとユニキャストルーティングエントリを含むように拡張されています。したがって、各マルチキャストルーティングエントリは、特定のVRFに関連付けられています。
Whether a particular VRF belongs to an MVPN or not is determined by configuration.
特定のVRFがMVPNに属しているかどうかは、構成によって決定されます。
In this document, we do not attempt to provide support for every possible multicast routing protocol that could possibly run on the PE-CE link. Rather, we consider multicast C-instances only for the following multicast routing protocols:
このドキュメントでは、PE-CEリンクで実行できる可能性のあるあらゆるマルチキャストルーティングプロトコルのサポートを提供しようとはしません。むしろ、次のマルチキャストルーティングプロトコルについてのみマルチキャストCインスタンスを検討します。
- PIM Sparse Mode (PIM-SM), supporting the ASM service model
- ASMサービスモデルをサポートするPIMスパースモード（PIM-SM）
- PIM Sparse Mode, supporting the SSM service model
- SSMサービスモデルをサポートするPIMスパースモード
- PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional C-trees to support the ASM service model.
- PIM双方向モード（Bidir-PIM）。これは、双方向Cツリーを使用してASMサービスモデルをサポートします。
In order to support the "Carrier's Carrier" model of [RFC4364], mLDP may also be supported on the PE-CE interface. The use of mLDP on the PE-CE interface is described in [MVPN-BGP].
[RFC4364]の「キャリアキャリア」モデルをサポートするために、MLDPもPE-CEインターフェイスでサポートされる場合があります。PE-CEインターフェイスでのMLDPの使用は、[MVPN-BGP]で説明されています。
The use of BGP on the PE-CE interface is not within the scope of this document.
PE-CEインターフェイスでのBGPの使用は、このドキュメントの範囲内ではありません。
As the only multicast C-instances discussed by this document are PIM-based C-instances, we will generally use the term "PIM C-instances" to refer to the multicast C-instances.
このドキュメントで議論されたマルチキャストCインスタンスはPIMベースのCインスタンスであるため、一般に「PIM Cインスタンス」という用語を使用して、マルチキャストCインスタンスを参照します。
A PE router may also be running a "provider-wide" instance of PIM, (a "PIM P-instance"), in which it has a PIM adjacency with, e.g., each of its IGP neighbors (i.e., with P routers), but NOT with any CE routers, and not with other PE routers (unless another PE router happens to be an IGP adjacency). In this case, P routers would also run the P-instance of PIM but NOT a C-instance. If there is a PIM P-instance, it may or may not have a role to play in the support of VPN multicast; this is discussed in later sections. However, in no case will the PIM P-instance contain VPN-specific multicast routing information.
PEルーターは、PIMの「プロバイダー全体の」インスタンス（「PIM P-instance」）の「プロバイダー全体」インスタンスを実行している場合があります。この場合、それぞれのIGPネイバー（つまり、Pルーターを使用）を備えたPIM隣接があります。、しかし、CEルーターではなく、他のPEルーターではありません（別のPEルーターがたまたまIGPの隣接性でない限り）。この場合、PルーターはPIMのpインスタンスも実行されますが、Cインスタンスではありません。PIM Pインスタンスがある場合、VPNマルチキャストのサポートに役立つ役割がある場合とそうでない場合があります。これについては、後のセクションで説明します。ただし、PIM PインスタンスにはVPN固有のマルチキャストルーティング情報が含まれていません。
In order to help clarify when we are speaking of the PIM P-instance and when we are speaking of a PIM C-instance, we will also apply the prefixes "P-" and "C-", respectively, to control messages, addresses, etc. Thus, a P-Join would be a PIM Join that is processed by the PIM P-instance, and a C-Join would be a PIM Join that is processed by a C-instance. A P-group address would be a group address in the SP's address space, and a C-group address would be a group address in a VPN's address space. A C-tree is a multicast distribution tree constructed and maintained by the PIM C-instances. A C-flow is a stream of multicast packets with a common C-source address and a common C-group address. We will use the notation "(C-S,C-G)" to identify specific C-flows. If a particular C-tree is a shared tree (whether unidirectional or bidirectional) rather than a source-specific tree, we will sometimes speak of the entire set of flows traveling that tree, identifying the set as "(C-*,C-G)".
PIM Pインスタンスについて話しているときとPIM Cインスタンスについて話しているときに明確にするために、それぞれ「P-」と「C-」のプレフィックスを適用して、メッセージ、アドレスを制御するために適用します。したがって、P-JoinはPIM Pインスタンスによって処理されるPIM結合であり、C-JoinはCインスタンスで処理されるPIM結合です。Pグループアドレスは、SPのアドレス空間のグループアドレスであり、CグループアドレスはVPNのアドレススペースのグループアドレスです。C-Treeは、PIM Cインスタンスによって構築および維持されるマルチキャスト配布ツリーです。C-flowは、共通のCソースアドレスと共通のCグループアドレスを備えたマルチキャストパケットのストリームです。表記「（c-s、c-g）」を使用して、特定のc-flowを識別します。特定のc-Treeがソース固有のツリーではなく共有ツリー（単方向または双方向であろうと）である場合、そのツリーを移動する流れのセット全体を時々話し、セットを「（c-*、c-g）と識別します。"。
A PE must have the ability to forward multicast data packets received from a CE to one or more of the other PEs in the same MVPN for delivery to one or more other CEs.
PEには、CEから受け取ったマルチキャストデータパケットを、同じMVPN内の1つまたは複数の他のCESに1つ以上の他のCESに送信する機能が必要です。
We define the notion of a "P-Multicast Service Interface" (PMSI). If a particular MVPN is supported by a particular set of PE routers, then there will be one or more PMSIs connecting those PE routers and/or subsets thereof. A PMSI is a conceptual "overlay" on the P-network with the following property: a PE in a given MVPN can give a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.
「P-Multicast Service Interface」（PMSI）の概念を定義します。特定のMVPNが特定のPEルーターのセットによってサポートされている場合、それらのPEルーターおよび/またはそのサブセットを接続する1つ以上のPMSIがあります。PMSIは、次のプロパティを備えたPネットワークの概念的な「オーバーレイ」です。特定のMVPNのPEはPMSIにパケットを与えることができ、パケットはMVPNの他のPEの一部またはすべてに配信されます。パケットを受信するPEが、パケットが属するMVPNを決定できるようになります。
As we discuss below, a PMSI may be instantiated by a number of different transport mechanisms, depending on the particular requirements of the MVPN and of the SP. We will refer to these transport mechanisms as "P-tunnels".
以下で説明するように、PMSIは、MVPNおよびSPの特定の要件に応じて、さまざまな輸送メカニズムによってインスタンス化される場合があります。これらの輸送メカニズムを「P-Tunnels」と呼びます。
For each MVPN, there are one or more PMSIs that are used for transmitting the MVPN's multicast data from one PE to others. We will use the term "PMSI" such that a single PMSI belongs to a single MVPN. However, the transport mechanism that is used to instantiate a PMSI may allow a single P-tunnel to carry the data of multiple PMSIs.
各MVPNについて、MVPNのマルチキャストデータを1つのPEから他のPEに送信するために使用される1つ以上のPMSIがあります。単一のPMSIが単一のMVPNに属するように、「PMSI」という用語を使用します。ただし、PMSIをインスタンス化するために使用される輸送メカニズムにより、単一のPトンネルが複数のPMSIのデータを運ぶことができます。
In this document, we make a clear distinction between the multicast service (the PMSI) and its instantiation. This allows us to separate the discussion of different services from the discussion of different instantiations of each service. The term "P-tunnel" is used to refer to the transport mechanism that instantiates a service.
このドキュメントでは、マルチキャストサービス（PMSI）とそのインスタンス化を明確に区別します。これにより、さまざまなサービスの議論を、各サービスのさまざまなインスタンス化の議論から分離することができます。「P-tunnel」という用語は、サービスをインスタンス化する輸送メカニズムを指すために使用されます。
PMSIs are used to carry C-multicast data traffic. The C-multicast data traffic travels along a C-tree, but in the SP backbone all C-trees are tunneled through P-tunnels. Thus, we will sometimes talk of a P-tunnel carrying one or more C-trees.
PMSIは、C-Multicastデータトラフィックを運ぶために使用されます。c-multicastデータトラフィックはc-treeに沿って移動しますが、SPバックボーンではすべてのCトリーがp-tunnelsを通じてトンネルされています。したがって、私たちは時々、1つ以上のCツリーを運ぶPトンネルについて話します。
Some of the options for passing multicast control traffic among the PEs do so by sending the control traffic through a PMSI; other options do not send control traffic through a PMSI.
PES間でマルチキャスト制御トラフィックを渡すためのオプションのいくつかは、PMSIを介して制御トラフィックを送信することによりそうします。他のオプションは、PMSIを介して制御トラフィックを送信しません。
We will distinguish between three different kinds of PMSIs:
3つの異なる種類のPMSIを区別します。
- "Multidirectional Inclusive" PMSI (MI-PMSI)
- 「多方向包括的」PMSI（MI-PMSI）
A Multidirectional Inclusive PMSI is one that enables ANY PE attaching to a particular MVPN to transmit a message such that it will be received by EVERY other PE attaching to that MVPN.
多方向包括的PMSIは、特定のMVPNに接続するPEが、そのMVPNに付着する他のすべてのPEによって受信されるようにメッセージを送信できるようにするものです。
There is, at most, one MI-PMSI per MVPN. (Though the P-tunnel or P-tunnels that instantiate an MI-PMSI may actually carry the data of more than one PMSI.)
せいぜい、MVPNごとに1つのMi-PMSIがあります。（Mi-PMSIをインスタンス化するPトンネルまたはPタンネルは、実際に複数のPMSIのデータを実際に運ぶ可能性があります。）
An MI-PMSI can be thought of as an overlay broadcast network connecting the set of PEs supporting a particular MVPN.
Mi-PMSIは、特定のMVPNをサポートするPESのセットを接続するオーバーレイブロードキャストネットワークと考えることができます。
- "Unidirectional Inclusive" PMSI (UI-PMSI)
- 「単方向包括的」PMSI（UI-PMSI）
A Unidirectional Inclusive PMSI is one that enables a particular PE, attached to a particular MVPN, to transmit a message such that it will be received by all the other PEs attaching to that
単方向の包括的PMSIは、特定のMVPNに接続された特定のPEを可能にするものであり、それに付着する他のすべてのPEによって受信されるようにメッセージを送信できます。
MVPN. There is, at most, one UI-PMSI per PE per MVPN, though the P-tunnel that instantiates a UI-PMSI may, in fact, carry the data of more than one PMSI.
MVPN。MVPNごとに1つのUI-PMSIが1つあたり1つのUI-PMSIがありますが、UI-PMSIをインスタンス化するPトンネルは、実際には複数のPMSIのデータを運ぶ可能性があります。
- "Selective" PMSI (S-PMSI).
- 「選択的」PMSI（S-PMSI）。
A Selective PMSI is one that provides a mechanism wherein a particular PE in an MVPN can multicast messages so that they will be received by a subset of the other PEs of that MVPN. There may be an arbitrary number of S-PMSIs per PE per MVPN. The P-tunnel that instantiates a given S-PMSI may carry data from multiple S-PMSIs.
選択的なPMSIは、MVPNの特定のPEがマルチキャストメッセージを使用して、そのMVPNの他のPESのサブセットによって受信できるメカニズムを提供するものです。MVPNあたりPEあたりのS-PMSIの数が任意にある場合があります。特定のS-PMSIをインスタンス化するPトンネルは、複数のS-PMSIからデータを伝達する場合があります。
In later sections, we describe the role played by these different kinds of PMSIs. We will use the term "I-PMSI" when we are not distinguishing between "MI-PMSIs" and "UI-PMSIs".
後のセクションでは、これらのさまざまな種類のPMSIが果たす役割について説明します。「Mi-PMSIS」と「UI-PMSIS」を区別していない場合は、「I-PMSI」という用語を使用します。
The P-tunnels that are used to instantiate PMSIs will be referred to as "P-tunnels". A number of different tunnel setup techniques can be used to create the P-tunnels that instantiate the PMSIs. Among these are the following:
PMSIをインスタンス化するために使用されるPタンネルは、「P-Tunnels」と呼ばれます。多くの異なるトンネルセットアップ手法を使用して、PMSIをインスタンス化するPトンネルを作成できます。これらの中には、次のとおりです。
- PIM
- ピム
A PMSI can be instantiated as (a set of) Multicast Distribution trees created by the PIM P-instance ("P-trees").
PMSIは、PIM Pインスタンス（「P-Tree」）によって作成されたマルチキャスト分布ツリーの（「P-Tree」）としてインスタンス化できます。
The multicast distribution trees that instantiate I-PMSIs may be either shared trees or source-specific trees.
I-PMSISをインスタンス化するマルチキャスト分布ツリーは、共有ツリーまたはソース固有の木のいずれかである可能性があります。
This document (along with [MVPN-BGP]) specifies procedures for identifying a particular (C-S,C-G) flow and assigning it to a particular S-PMSI. Such an S-PMSI is most naturally instantiated as a source-specific tree.
このドキュメント（[MVPN-BGP]とともに）は、特定の（C-S、C-G）フローを識別し、特定のS-PMSIに割り当てる手順を指定します。このようなS-PMSIは、ソース固有のツリーとして最も自然にインスタンス化されています。
The use of shared trees (including bidirectional trees) to instantiate S-PMSIs is outside the scope of this document.
S-PMSISをインスタンス化するために共有ツリー（双方向ツリーを含む）を使用することは、このドキュメントの範囲外です。
The use of PIM-DM to create P-tunnels is not supported.
P-Tunnelを作成するためにPIM-DMを使用することはサポートされていません。
P-tunnels may be shared by multiple MVPNs (i.e., a given P-tunnel may be the instantiation of multiple PMSIs), as long as the tunnel encapsulation provides some means of demultiplexing the data traffic by MVPN.
トンネルのカプセル化がMVPNによってデータトラフィックを非難する何らかの手段を提供する限り、Pタンネルは複数のMVPN（つまり、特定のPトンネルは複数のPMSIのインスタンス化である可能性があります）によって共有される場合があります。
- mLDP
- MLDP
mLDP Point-to-Multipoint (P2MP) LSPs or Multipoint-to-Multipoint (MP2MP) LSPs can be used to instantiate I-PMSIs.
MLDP Point-to-Multipoint（P2MP）LSPまたはMultipoint-to-MultiPoint（MP2MP）LSPを使用して、I-PMSISをインスタンス化できます。
An S-PMSI or a UI-PMSI could be instantiated as a single mLDP P2MP LSP, whereas an MI-PMSI would have to be instantiated as a set of such LSPs (each PE in the MVPN being the root of one such LSP) or as a single MP2MP LSP.
S-PMSIまたはUI-PMSIは単一のMLDP P2MP LSPとしてインスタンス化できますが、Mi-PMSIはそのようなLSPのセットとしてインスタンス化する必要があります（MVPNの各PEはそのようなLSPのルートです）または単一のmp2mp lspとして。
Procedures for sharing MP2MP LSPs across multiple MVPNs are outside the scope of this document.
複数のMVPNでMP2MP LSPを共有する手順は、このドキュメントの範囲外です。
The use of MP2MP LSPs to instantiate S-PMSIs is outside the scope of this document.
S-PMSISをインスタンス化するためのMP2MP LSPの使用は、このドキュメントの範囲外です。
Section 11.2.3 discusses a way of using a partial mesh of MP2MP LSPs to instantiate a PMSI. However, a full specification of the necessary procedures is outside the scope of this document.
セクション11.2.3では、MP2MP LSPの部分メッシュを使用してPMSIをインスタンス化する方法について説明します。ただし、必要な手順の完全な仕様は、このドキュメントの範囲外です。
- RSVP-TE
- RSVP-TE
A PMSI may be instantiated as one or more RSVP-TE Point-to-Multipoint (P2MP) LSPs. An S-PMSI or a UI-PMSI would be instantiated as a single RSVP-TE P2MP LSP, whereas a Multidirectional Inclusive PMSI would be instantiated as a set of such LSPs, one for each PE in the MVPN. RSVP-TE P2MP LSPs can be shared across multiple MVPNs.
PMSIは、1つ以上のRSVP-TEポイントツーマルチポイント（P2MP）LSPとしてインスタンス化される場合があります。S-PMSIまたはUI-PMSIは、単一のRSVP-TE P2MP LSPとしてインスタンス化されますが、多方向包摂的PMSIは、MVPNの各PEに1つずつ、そのようなLSPのセットとしてインスタンス化されます。RSVP-TE P2MP LSPは、複数のMVPNで共有できます。
- A Mesh of Unicast P-Tunnels.
- ユニキャストPタンネルのメッシュ。
If a PMSI is implemented as a mesh of unicast P-tunnels, a PE wishing to transmit a packet through the PMSI would replicate the packet and send a copy to each of the other PEs.
PMSIがユニキャストPターンネルのメッシュとして実装されている場合、PMSIを介してパケットを送信したいPEがパケットを複製し、他の各PEにコピーを送信します。
An MI-PMSI for a given MVPN can be instantiated as a full mesh of unicast P-tunnels among that MVPN's PEs. A UI-PMSI or an S-PMSI can be instantiated as a partial mesh.
特定のMVPNのMi-PMSIは、そのMVPNのPESの中でユニキャストPターンネルの完全なメッシュとしてインスタンス化できます。UI-PMSIまたはS-PMSIは、部分メッシュとしてインスタンス化できます。
It can be seen that each method of implementing PMSIs has its own area of applicability. Therefore, this specification allows for the use of any of these methods. At first glance, this may seem like an overabundance of options. However, the history of multicast development and deployment should make it clear that there is no one option that is always acceptable. The use of segmented inter-AS trees does allow each SP to select the option that it finds most applicable in its own environment, without causing any other SP to choose that same option.
PMSIを実装する各方法には、独自の適用領域があることがわかります。したがって、この仕様により、これらの方法のいずれかを使用できます。一見すると、これはオプションの過剰のように思えるかもしれません。ただし、マルチキャストの開発と展開の歴史により、常に受け入れられる選択肢がないことが明らかになるはずです。セグメント化されたツリーを使用すると、各SPが独自の環境で最も適用可能なオプションを選択でき、他のSPが同じオプションを選択することなく選択できます。
SPECIFYING THE CONDITIONS UNDER WHICH A PARTICULAR TREE-BUILDING METHOD IS APPLICABLE IS OUTSIDE THE SCOPE OF THIS DOCUMENT.
特定のツリービルディング方法が適用される条件を指定することは、このドキュメントの範囲外です。
The choice of the tunnel technique belongs to the sender router and is a local policy decision of that router. The procedures defined throughout this document do not mandate that the same tunnel technique be used for all P-tunnels going through a given provider backbone. However, it is expected that any tunnel technique that can be used by a PE for a particular MVPN is also supported by all the other PEs having VRFs for the MVPN. Moreover, the use of ingress replication by any PE for an MVPN implies that all other PEs MUST use ingress replication for this MVPN.
トンネル技術の選択は、送信者ルーターに属し、そのルーターのローカルポリシー決定です。このドキュメント全体で定義された手順は、特定のプロバイダーバックボーンを通過するすべてのPトゥンネルに同じトンネル技術を使用することを義務付けていません。ただし、特定のMVPNにPEで使用できるトンネル技術は、MVPNのVRFを持っている他のすべてのPESによってサポートされることが予想されます。さらに、MVPNのPEによるイングレス複製の使用は、他のすべてのPEがこのMVPNにイングレスレプリケーションを使用する必要があることを意味します。
Each PE supporting a particular MVPN must have a way of discovering the following information:
特定のMVPNをサポートする各PEには、次の情報を発見する方法が必要です。
- The set of other PEs in its AS that are attached to sites of that MVPN, and the set of other ASes that have PEs attached to sites of that MVPN. However, if non-segmented inter-AS trees are used (see Section 8.1), then each PE needs to know the entire set of PEs attached to sites of that MVPN.
- その中の他のPESのセットは、そのMVPNのサイトに接続されているもの、およびそのMVPNのサイトにPESが付着している他のASのセット。ただし、セグメント化されていないAS間のツリーを使用する場合（セクション8.1を参照）、各PEはそのMVPNのサイトに接続されたPEのセット全体を知る必要があります。
- If segmented inter-AS trees are to be used, the set of border routers in its AS that support inter-AS connectivity for that MVPN.
- セグメント化されたasの樹木を使用する場合、そのMVPNの接続性としての接続性をサポートする境界線ルーターのセット。
- If the MVPN is configured to use an MI-PMSI, the information needed to set up and to use the P-tunnels instantiating the MI-PMSI.
- MVPNがMi-PMSIを使用するように構成されている場合、Mi-PMSIをインスタンス化するP-Tunnelsを設定して使用するために必要な情報。
- For each other PE, whether the PE supports Aggregate Trees for the MVPN, and if so, the demultiplexing information that must be provided so that the other PE can determine whether a packet that it received on an Aggregate Tree belongs to this MVPN.
- PEがMVPNの骨材をサポートするかどうか、もしそうなら、他のPEが骨材で受信したパケットがこのMVPNに属しているかどうかを判断できるように提供する必要がある非複数の情報を提供するかどうか。
In some cases, the information above is provided by means of the BGP-based auto-discovery procedures discussed in Section 4 of this document and in Section 9 of [MVPN-BGP]. In other cases, this information is provided after discovery is complete, by means of procedures discussed in Section 7.4. In either case, the information that is provided must be sufficient to enable the PMSI to be bound to the identified P-tunnel, to enable the P-tunnel to be created if it does not already exist, and to enable the different PMSIs that may travel on the same P-tunnel to be properly demultiplexed.
場合によっては、上記の情報は、このドキュメントのセクション4および[MVPN-BGP]のセクション9で説明されているBGPベースの自動配分手順によって提供されます。他のケースでは、この情報は、セクション7.4で説明されている手順によって、発見が完了した後に提供されます。どちらの場合でも、提供される情報は、PMSIを特定したPトンネルに拘束できるようにし、P-tunnelがまだ存在しない場合に作成できるようにし、可能性のある異なるPMSIを有効にするには、十分なものでなければなりません。同じPトンネルで移動して、適切に反転します。
If an MVPN uses an MI-PMSI, then the information needed to identify the P-tunnels that instantiate the MI-PMSI has to be known to the PEs attached to the MVPN before any data can be transmitted on the MI-PMSI. This information is either statically configured or auto-discovered (see Section 4). The actual process of constructing the P-tunnels (e.g., via PIM, RSVP-TE, or mLDP) SHOULD occur as soon as this information is known.
MVPNがMi-PMSIを使用する場合、MI-PMSIをインスタンス化するP-PSIをMVPNに接続しているPESに識別するために必要な情報は、MI-PMSIにデータを送信することができます。この情報は、静的に構成されているか、自動設定されています（セクション4を参照）。Pタンネルを構築する実際のプロセス（たとえば、PIM、RSVP-TE、またはMLDP経由）は、この情報がわかったらすぐに発生するはずです。
When MI-PMSIs are used, they may serve as the default method of carrying C-multicast data traffic. When we say that an MI-PMSI is the "default" method of carrying C-multicast data traffic for a particular MVPN, we mean that it is not necessary to use any special control procedures to bind a particular C-flow to the MI-PMSI; any C-flows that have not been bound to other PMSIs will be assumed to travel through the MI-PMSI.
MI-PMSISを使用すると、C-Multicastデータトラフィックを運ぶデフォルトの方法として機能する場合があります。Mi-PMSIが特定のMVPNのCマルチキャストデータトラフィックを運ぶ「デフォルト」方法であると言う場合、特定のCフローをMIに結合するために特別な制御手順を使用する必要がないことを意味します。PMSI;他のPMSIに縛られていないCフローは、Mi-PMSIを通過すると想定されます。
There is no requirement to use MI-PMSIs as the default method of carrying C-flows. It is possible to adopt a policy in which all C-flows are carried on UI-PMSIs or S-PMSIs. In this case, if an MI-PMSI is not used for carrying routing information, it is not needed at all.
C-Flowを運ぶデフォルトの方法としてMI-PMSISを使用する必要はありません。すべてのC-FlowがUI-PMSISまたはS-PMSISで運ばれるポリシーを採用することが可能です。この場合、Mi-PMSIがルーティング情報を運ぶために使用されない場合、まったく必要ありません。
Even when an MI-PMSI is used as the default method of carrying an MVPN's C-flows, if a particular C-flow has certain characteristics, it may be desirable to migrate it from the MI-PMSI to an S-PMSI. These characteristics, as well as the procedures for migrating a C-flow from an MI-PMSI to an S-PMSI, are discussed in Section 7.
MI-PMSIがMVPNのCフローを運ぶデフォルトの方法として使用されている場合でも、特定のCフローに特定の特性がある場合、Mi-PMSIからS-PMSIに移行することが望ましい場合があります。これらの特性と、CフローをMi-PMSIからS-PMSIに移行する手順については、セクション7で説明します。
Sometimes a set of C-flows are traveling the same, shared, C-tree (e.g., either unidirectional or bidirectional), and it may be desirable to move the whole set of C-flows as a unit to an S-PMSI. Procedures for doing this are outside the scope of this specification.
C-flowのセットが同じ、共有、Cツリー（例えば、単方向または双方向のいずれか）を移動している場合があり、C-Flowのセット全体をユニットとしてS-PMSIに移動することが望ましい場合があります。これを行うための手順は、この仕様の範囲外です。
Some of the procedures for transmitting C-multicast routing information among the PEs require that the routing information be sent over an MI-PMSI. Other procedures do not use an MI-PMSI to transmit the C-multicast routing information.
PEの間でC-Multicastルーティング情報を送信する手順の一部では、ルーティング情報をMi-PMSIで送信する必要があります。他の手順では、MI-PMSIを使用してC-Multicastルーティング情報を送信しません。
For a given MVPN, whether an MI-PMSI is used to carry C-multicast routing information is independent from whether an MI-PMSI is used as the default method of carrying the C-multicast data traffic.
特定のMVPNの場合、MI-PMSIがC-Multicastルーティング情報を携帯するために使用されるかどうかは、MI-PMSIがC-Multicastデータトラフィックを運ぶデフォルトの方法として使用されるかどうかとは独立しています。
As previously stated, it is possible to send all C-flows on a set of S-PMSIs, omitting any usage of I-PMSIs. This prevents PEs from receiving data that they don't need, at the cost of requiring additional P-tunnels, and additional signaling to bind the C-flows to P-tunnels. Cost-effective instantiation of S-PMSIs is likely to
前述のように、I-PMSISの使用を省略して、すべてのC-FlowをS-PMSISのセットに送信することができます。これにより、PESが必要としないデータを受信し、追加のPタンネルを必要とするコストで、およびCフローをPタンネルに結合するための追加のシグナル伝達が防止されます。S-PMSISの費用対効果の高いインスタンス化は可能性があります
require Aggregate P-trees, which, in turn, makes it necessary for the transmitting PE to know which PEs need to receive which multicast streams. This is known as "explicit tracking", and the procedures to enable explicit tracking may themselves impose a cost. This is further discussed in Section 7.4.1.2.
集約P-Treeが必要です。これにより、送信PEがどのマルチキャストストリームを受信する必要があるかを知るために必要なものが必要になります。これは「明示的な追跡」として知られており、明示的な追跡を有効にする手順自体がコストを課す可能性があります。これについては、セクション7.4.1.2でさらに説明します。
As a PE attached to a given MVPN receives C-Join/Prune messages from its CEs in that MVPN, it must convey the information contained in those messages to other PEs that are attached to the same MVPN.
特定のMVPNに接続されているPEは、そのMVPNのCESからC-Join/Pruneメッセージを受信するため、それらのメッセージに含まれる情報を同じMVPNに接続されている他のPEに伝える必要があります。
There are several different methods for doing this. As these methods are not interoperable, the method to be used for a particular MVPN must be either configured or discovered as part of the auto-discovery process.
これを行うにはいくつかの異なる方法があります。これらの方法は相互運用できないため、特定のMVPNに使用する方法は、自動配記プロセスの一部として構成または検出される必要があります。
If the set of PEs attached to a given MVPN are connected via an MI-PMSI, the PEs can form "normal" PIM adjacencies with each other. Since the MI-PMSI functions as a broadcast network, the standard PIM procedures for forming and maintaining adjacencies over a LAN can be applied.
特定のMVPNに接続されたPESのセットがMi-PMSIを介して接続されている場合、PESは互いに「通常の」PIM隣接を形成できます。Mi-PMSIはブロードキャストネットワークとして機能するため、LANを介して隣接を形成および維持するための標準的なPIM手順を適用できます。
As a result, the C-Join/Prune messages that a PE receives from a CE can be multicast to all the other PEs of the MVPN. PIM "Join suppression" can be enabled and the PEs can send Asserts as needed.
その結果、PEがCEから受信するC結合/プルーンメッセージは、MVPNの他のすべてのPESにマルチキャストになります。PIM「結合抑制」を有効にすることができ、PESは必要に応じてアサートを送信できます。
This procedure is fully specified in Section 5.2.
この手順は、セクション5.2で完全に指定されています。
The procedure of the previous Section has the following disadvantages:
前のセクションの手順には、次の欠点があります。
- Periodic Hello messages must be sent by all PEs.
- 定期的なハローメッセージは、すべてのPEによって送信する必要があります。
Standard PIM procedures require that each PE in a particular MVPN periodically multicast a Hello to all the other PEs in that MVPN. If the number of MVPNs becomes very large, sending and receiving these Hellos can become a substantial overhead for the PE routers.
標準のPIM手順では、特定のMVPN内の各PEが定期的にマルチキャストATH MVPNの他のすべてのPEに挨拶する必要があります。MVPNの数が非常に大きくなった場合、これらのHellosを送信および受信することは、PEルーターのかなりのオーバーヘッドになる可能性があります。
- Periodic retransmission of C-Join/Prune messages.
- C-Join/Pruneメッセージの定期的な再送信。
PIM is a "soft-state" protocol, in which reliability is assured through frequent retransmissions (refresh) of control messages. This too can begin to impose a large overhead on the PE routers as the number of MVPNs grows.
PIMは「ソフトステート」プロトコルであり、コントロールメッセージの頻繁な再送信（更新）を通じて信頼性が保証されます。これも、MVPNの数が増えるにつれて、PEルーターに大きなオーバーヘッドを課し始める可能性があります。
The first of these disadvantages is easily remedied. The reason for the periodic PIM Hellos is to ensure that each PIM speaker on a LAN knows who all the other PIM speakers on the LAN are. However, in the context of MVPN, PEs in a given MVPN can learn the identities of all the other PEs in the MVPN by means of the BGP-based auto-discovery procedure of Section 4. In that case, the periodic Hellos would serve no function and could simply be eliminated. (Of course, this does imply a change to the standard PIM procedures.)
これらの欠点の最初は簡単に改善されます。定期的なPIM Hellosの理由は、LAN上の各PIMスピーカーがLAN上の他のすべてのPIMスピーカーが誰であるかを確認することです。ただし、MVPNのコンテキストでは、指定されたMVPNのPESは、セクション4のBGPベースの自動配置手順により、MVPNの他のすべてのPEのアイデンティティを学習できます。その場合、周期的なHellosはNOに役立ちます。機能と単純に排除できます。（もちろん、これは標準のPIM手順の変更を意味します。）
When Hellos are suppressed, we may speak of "lightweight PIM peering".
Hellosが抑制されると、「軽量のPim Peering」について話すことができます。
The periodic refresh of the C-Join/Prune messages is not as simple to eliminate. If and when "refresh reduction" procedures are specified for PIM, it may be useful to incorporate them, so as to make the lightweight PIM peering procedures even more lightweight.
C-Join/Pruneメッセージの定期的な更新は、排除するのが簡単ではありません。PIMに「更新削減」手順が指定されている場合、軽量のPIMピアリング手順をさらに軽量にするために、それらを組み込むことが役立つ場合があります。
Lightweight PIM peering is not specified in this document.
このドキュメントでは、軽量のPIM Peeringは指定されていません。
PIM does not require that the C-Join/Prune messages that a PE receives from a CE to be multicast to all the other PEs; it allows them to be unicast to a single PE, the one that is upstream on the path to the root of the multicast tree mentioned in the Join/Prune message. Note that when the C-Join/Prune messages are unicast, there is no such thing as "Join suppression". Therefore, PIM Refresh Reduction may be considered to be a prerequisite for the procedure of unicasting the C-Join/Prune messages.
PIMは、PEがCEから受信するC結合/プルーンメッセージを他のすべてのPEにマルチキャストすることを必要としません。これにより、単一のPEにユニキャストすることができます。これは、Join/Pruneメッセージに記載されているマルチキャストツリーのルートへのパス上に上流にあるものです。C-Join/PruneメッセージがUnicastである場合、「抑制に参加」などはないことに注意してください。したがって、PIMリフレッシュの削減は、C結合/プルーンメッセージのユニカストの手順の前提条件であると見なされる場合があります。
When the C-Join/Prune messages are unicast, they are not transmitted on a PMSI at all. Note that the procedure of unicasting the C-Join/Prune messages is different than the procedure of transmitting the C-Join/Prune messages on an MI-PMSI that is instantiated as a mesh of unicast P-tunnels.
C-Join/PruneメッセージがUnicastの場合、PMSIにはまったく送信されません。C-Goin/Pruneメッセージの単梱符を固定する手順は、Unicast P-Tunnelのメッシュとしてインスタンス化されたMi-PMSIでC-Goin/Pruneメッセージを送信する手順とは異なることに注意してください。
If there are multiple PEs that can be used to reach a given C-source, procedures described in Sections 5.1 and 9 MUST be used to ensure that duplicate packets do not get delivered.
特定のCソースに到達するために使用できる複数のPEがある場合、セクション5.1および9で説明されている手順を使用して、重複パケットが配信されないようにする必要があります。
Procedures for unicasting the PIM control messages are not further specified in this document.
このドキュメントでは、PIMコントロールメッセージを単一施設する手順はさらに指定されていません。
It is possible to use BGP to carry C-multicast routing information from PE to PE, dispensing entirely with the transmission of C-Join/Prune messages from PE to PE. This is discussed in Section 5.3 and fully specified in [MVPN-BGP].
BGPを使用してC-Multicastルーティング情報をPEからPEへのルーティング情報を運ぶことができ、PEからPEへのC結合/プルーンメッセージの送信を完全に分配することができます。これについては、セクション5.3で説明し、[MVPN-BGP]で完全に指定されています。
BGP-based auto-discovery is done by means of a new address family, the MCAST-VPN address family. (This address family also has other uses, as will be seen later.) Any PE that attaches to an MVPN must issue a BGP Update message containing an NLRI ("Network Layer Reachability Information" element) in this address family, along with a specific set of attributes. In this document, we specify the information that must be contained in these BGP Updates in order to provide auto-discovery. The encoding details, along with the complete set of detailed procedures, are specified in a separate document [MVPN-BGP].
BGPベースの自動ディスコーブリは、新しいアドレスファミリーであるMCAST-VPNアドレスファミリーによって行われます。（このアドレスファミリには、後で見られるように、他の用途もあります。）MVPNに接続するPEは、このアドレスファミリにNLRI（「ネットワークレイヤーリーチビリティ情報」要素）を含むBGPアップデートメッセージを、特定のものとともに発行する必要があります。属性のセット。このドキュメントでは、自動発見を提供するために、これらのBGP更新に含める必要がある情報を指定します。エンコーディングの詳細は、詳細な手順の完全なセットとともに、別のドキュメント[MVPN-BGP]で指定されています。
This section specifies the intra-AS BGP-based auto-discovery procedures. When segmented inter-AS trees are used, additional procedures are needed, as specified in [MVPN-BGP]. (When segmented inter-AS trees are not used, the inter-AS procedures are almost identical to the intra-AS procedures.)
このセクションでは、BGPベースのASINTRA AUTO DISCOVERY手順を指定します。[MVPN-BGP]で指定されているように、セグメント化されたTreesを使用する場合、追加の手順が必要です。（セグメント化された樹木間ツリーが使用されない場合、AS間の手順は、AS Intra-ASの手順とほぼ同じです。）
BGP-based auto-discovery uses a particular kind of MCAST-VPN route known as an "auto-discovery route", or "A-D route". In particular, it uses two kinds of "A-D routes": the "Intra-AS I-PMSI A-D route" and the "Inter-AS I-PMSI A-D route". (There are also additional kinds of A-D routes, such as the Source Active A-D routes, which are used for purposes that go beyond auto-discovery. These are discussed in subsequent sections.)
BGPベースの自動ディスコーブリーは、「自動ディスコーブリルート」または「A-Dルート」として知られる特定の種類のMCAST-VPNルートを使用します。特に、2種類の「A-Dルート」を使用します。「Intra-as I-PMSI A-Dルート」と「INTER-AS I-PMSI A-Dルート」です。（自動発見を超えた目的に使用されるソースアクティブA-Dルートなど、追加の種類のA-Dルートもあります。これらは後続のセクションで説明されています。）
The Inter-AS I-PMSI A-D route is used only when segmented inter-AS P-tunnels are used, as specified in [MVPN-BGP].
INTER-AS I-PMSI A-Dルートは、[MVPN-BGP]で指定されているように、P-Tunnelsをセグメント化した場合にのみ使用されます。
The "Intra-AS I-PMSI A-D route" is originated by the PEs that are (directly) connected to the site(s) of an MVPN. It is distributed to other PEs that attach to sites of the MVPN. If segmented inter-AS P-tunnels are used, then the Intra-AS I-PMSI A-D routes are not distributed outside the AS where they originate; if segmented inter-AS P-tunnels are not used, then the Intra-AS I-PMSI A-D routes are, despite their name, distributed to all PEs attached to the VPN, no matter what AS the PEs are in.
「Intra-as I-PMSI A-Dルート」は、MVPNのサイトに（直接）接続されているPESから発信されます。MVPNのサイトに付着する他のPESに配布されます。セグメント化されたas p-tunnelsを使用する場合、Intra-as i-pmsi a-dルートは、それらが発生する場所として外部に分布していません。セグメント化されたas p-tunnelsが使用されていない場合、Intra-as-as-pmsi a-dルートは、その名前にもかかわらず、PESが何であれ、VPNに接続されたすべてのPEに分配されます。
The NLRI of an Intra-AS I-PMSI A-D route must contain the following information:
INTRA-AS I-PMSI A-DルートのNLRIには、次の情報が含まれている必要があります。
- The route type (i.e., Intra-AS I-PMSI A-D route).
- ルートタイプ（つまり、INTRA-AS I-PMSI A-Dルート）。
- The IP address of the originating PE.
- 発生PEのIPアドレス。
- An RD ("Route Distinguisher", [RFC4364]) configured locally for the MVPN. This is an RD that can be prepended to that IP address to form a globally unique VPN-IP address of the PE.
- MVPN用にローカルに構成されたRD（ "Route distiminger"、[rfc4364]）。これは、PEのグローバルに一意のVPN-IPアドレスを形成するためにそのIPアドレスに準備できるRDです。
Intra-AS I-PMSI A-D routes carry the following attributes:
Intra-as i-pmsi a-dルートには、次の属性が含まれます。
- Route Target Extended Communities attribute.
- ルートターゲット拡張コミュニティ属性。
One or more of these MUST be carried by each Intra-AS I-PMSI A-D route. If any other PE has one of these Route Targets configured for import into a VRF, it treats the advertising PE as a member in the MVPN to which the VRF belongs. This allows each PE to discover the PEs that belong to a given MVPN. More specifically, it allows a PE in the Receiver Sites set to discover the PEs in the Sender Sites set of the MVPN, and the PEs in the Sender Sites set of the MVPN to discover the PEs in the Receiver Sites set of the MVPN. The PEs in the Receiver Sites set would be configured to import the Route Targets advertised in the BGP A-D routes by PEs in the Sender Sites set. The PEs in the Sender Sites set would be configured to import the Route Targets advertised in the BGP A-D routes by PEs in the Receiver Sites set.
これらの1つ以上は、I-PMSI A-Dルートとしての各イントラによって運ばれる必要があります。他のPEにVRFへのインポート用に構成されたこれらのルートターゲットのいずれかがある場合、VRFが属するMVPNのメンバーとして広告PEを扱います。これにより、各PEは特定のMVPNに属するPEを発見できます。より具体的には、MVPNの送信者サイトセットのPESを発見し、MVPNの送信サイトセットのPESをMVPNの受信サイトセットの受信サイトセットのPESを発見することができます。セットされたレシーバーサイトのPESは、SenderサイトセットのPESによってBGP A-Dルートで宣伝されているルートターゲットをインポートするように構成されます。SenderサイトのPESは、レシーバーサイトセットのPESによってBGP A-Dルートで宣伝されているルートターゲットをインポートするように構成されます。
- PMSI Tunnel attribute.
- PMSIトンネル属性。
This attribute is present whenever the MVPN uses an MI-PMSI or when it uses a UI-PMSI rooted at the originating router. It contains the following information:
この属性は、MVPNがMi-PMSIを使用する場合、または発信元のルーターにルート化されたUI-PMSIを使用するときはいつでも存在します。次の情報が含まれています。
* tunnel technology, which may be one of the following:
* トンネルテクノロジー。これは次のいずれかです。
+ Bidirectional multicast tree created by BIDIR-PIM,
+ Bidir-Pimによって作成された双方向マルチキャストツリー、
+ Source-specific multicast tree created by PIM-SM, supporting the SSM service model,
+ SSMサービスモデルをサポートするPIM-SMによって作成されたソース固有のマルチキャストツリー、
+ Set of trees (one shared tree and a set of source trees) created by PIM-SM using the ASM service model,
+ ASMサービスモデルを使用してPIM-SMによって作成された木のセット（1つの共有ツリーとソースツリーのセット）、
+ Point-to-multipoint LSP created by RSVP-TE,
+ RSVP-TEによって作成されたポイントツーマルチポイントLSP、
+ Point-to-multipoint LSP created by mLDP,
+ MLDPによって作成されたポイントツーマルチポイントLSP、
+ multipoint-to-multipoint LSP created by mLDP
+ MLDPによって作成されたMultipoint-to-MultiPoint LSP
+ unicast tunnel
+ ユニキャストトンネル
* P-tunnel identifier
* Pトンネル識別子
Before a P-tunnel can be constructed to instantiate the I-PMSI, the PE must be able to create a unique identifier for the tunnel. The syntax of this identifier depends on the tunnel technology used.
I-PMSIをインスタンス化するためにPトンネルを構築する前に、PEはトンネルの一意の識別子を作成できる必要があります。この識別子の構文は、使用されるトンネル技術に依存します。
Each PE attaching to a given MVPN must be configured with information specifying the allowable encapsulations to use for that MVPN, as well as the particular one of those encapsulations that the PE is to identify in the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D routes that it originates.
特定のMVPNに付着する各PEは、そのMVPNに使用する許容可能なカプセル化を指定する情報で構成する必要があります。それが発生するA-Dルート。
* Multi-VPN aggregation capability and demultiplexor value.
* マルチVPNの集約機能と非屈筋値。
This specifies whether the P-tunnel is capable of aggregating I-PMSIs from multiple MVPNs. This will affect the encapsulation used. If aggregation is to be used, a demultiplexor value to be carried by packets for this particular MVPN must also be specified. The demultiplexing mechanism and signaling procedures are described in Section 6.
これは、Pトンネルが複数のMVPNからI-PMSIを集約できるかどうかを指定します。これは、使用されるカプセル化に影響します。集約を使用する場合、この特定のMVPNのパケットによって運ばれるデマルグリプレクサー値も指定する必要があります。脱臼メカニズムとシグナル伝達手順については、セクション6で説明します。
- PE Distinguisher Labels Attribute
- PE distinguisherラベル属性
Sometimes it is necessary for one PE to advertise an upstream-assigned MPLS label that identifies another PE. Under certain circumstances to be discussed later, a PE that is the root of a multicast P-tunnel will bind an MPLS label value to one or more of the PEs that belong to the P-tunnel, and it will distribute these label bindings using Intra-AS I-PMSI A-D routes.
あるPEが別のPEを識別する上流で割り当てられたMPLSラベルを宣伝する必要がある場合があります。後で説明する特定の状況では、マルチキャストPトンネルのルートであるPEがMPLSラベル値をPトンネルに属する1つ以上のPEにバインドし、Intraを使用してこれらのラベルバインディングを配布します。-PMSI A-Dルートとして。
Specification of when this must be done is provided in Sections 6.4.4 and 11.2.2. We refer to these as "PE Distinguisher Labels".
これをいつ行う必要があるかの仕様は、セクション6.4.4および11.2.2に記載されています。これらを「PE distiutisuisherラベル」と呼びます。
Note that, as specified in [MPLS-UPSTREAM-LABEL], PE Distinguisher Label values are unique only in the context of the IP address identifying the root of the P-tunnel; they are not necessarily unique per tunnel.
[mpls-upstream-label]で指定されているように、PE違いのラベル値は、Pトンネルのルートを識別するIPアドレスのコンテキストでのみ一意であることに注意してください。トンネルごとに必ずしもユニークではありません。
As a PE attached to a given MVPN receives C-Join/Prune messages from its CEs in that MVPN, it must convey the information contained in those messages to other PEs that are attached to the same MVPN. This is known as the "PE-PE transmission of C-multicast routing information".
特定のMVPNに接続されているPEは、そのMVPNのCESからC-Join/Pruneメッセージを受信するため、それらのメッセージに含まれる情報を同じMVPNに接続されている他のPEに伝える必要があります。これは、「C-Multicastルーティング情報のPE-PE伝送」として知られています。
This section specifies the procedures used for PE-PE transmission of C-multicast routing information. Not every procedure mentioned in Section 3.4 is specified here. Rather, this section focuses on two particular procedures:
このセクションでは、C-Multicastルーティング情報のPE-PE伝送に使用される手順を指定します。セクション3.4に記載されているすべての手順がここで指定されているわけではありません。むしろ、このセクションでは、2つの特定の手順に焦点を当てています。
- Full PIM Peering.
- フルピムピアリング。
This procedure is fully specified herein.
この手順は、本明細書で完全に指定されています。
- Use of BGP to distribute C-multicast routing
- C-Multicastルーティングを配布するためのBGPの使用
This procedure is described herein, but the full specification appears in [MVPN-BGP].
この手順についてはここで説明しますが、完全な仕様は[MVPN-BGP]に表示されます。
Those aspects of the procedures that apply to both of the above are also specified fully herein.
上記の両方に適用される手順のこれらの側面も、本明細書で完全に指定されています。
Specification of other procedures is outside the scope of this document.
他の手順の仕様は、このドキュメントの範囲外です。
When a PE receives a C-Join/Prune message from a CE, the message identifies a particular multicast flow as belonging either to a source-specific tree (S,G) or to a shared tree (*,G). Throughout this section, we use the term "C-root" to refer to S, in the case of a source-specific tree, or to the Rendezvous Point (RP) for G, in the case of (*,G). If the route to the C-root is across the VPN backbone, then the PE needs to find the "Upstream Multicast Hop" (UMH) for the (S,G) or (*,G) flow. The UMH is either the PE at which (S,G) or (*,G) data packets enter the VPN backbone or the Autonomous System Border Router (ASBR) at which those data packets enter the local AS when traveling through the VPN backbone. The process of finding the upstream multicast hop for a given C-root is known as "upstream multicast hop selection".
PEがCEからC結合/プルーンメッセージを受信すると、メッセージは特定のマルチキャストフローを、ソース固有のツリー（S、G）または共有ツリー（*、G）に属するものとして識別します。このセクション全体を通して、ソース固有のツリーの場合は、（*、g）の場合はgのランデブーポイント（rp）を参照する「c-root」という用語を使用します。CルートへのルートがVPNバックボーン全体にある場合、PEは（s、g）または（*、g）フローの「アップストリームマルチキャストホップ」（umh）を見つける必要があります。UMHは、VPNバックボーン（ASBR）に入る（S、G）または（*、G）データパケットがVPNバックボーンを通過するときのようにローカルに入る自律システムボーダールーター（ASBR）に入るPEのいずれかです。特定のCルートのアップストリームマルチキャストホップを見つけるプロセスは、「アップストリームマルチキャストホップ選択」として知られています。
In the simplest case, the PE does the upstream hop selection by looking up the C-root in the unicast VRF associated with the PE-CE interface over which the C-Join/Prune message was received. The route that matches the C-root will contain the information needed to select the UMH.
最も簡単な場合、PEは、C-Goin/Pruneメッセージが受信されたPE-CEインターフェイスに関連付けられたユニキャストVRFのC-Rootを調べることにより、上流のホップ選択を行います。C-Rootに一致するルートには、UMHを選択するために必要な情報が含まれます。
However, in some cases, the CEs may be distributing to the PEs a special set of routes that are to be used exclusively for the purpose of upstream multicast hop selection, and not used for unicast routing at all. For example, when BGP is the CE-PE unicast routing protocol, the CEs may be using Subsequent Address Family Identifier 2 (SAFI 2) to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection. When OSPF [OSPF] is the CE-PE routing protocol, the CE may use an MT-ID (Multi-Topology Identifier) [OSPF-MT] of 1 to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection. When a CE uses one of these mechanisms to distribute to a PE a special set of routes to be used exclusively for upstream multicast hop selection, these routes are distributed among the PEs using SAFI 129, as described in [MVPN-BGP]. Whether the routes used for upstream multicast hop selection are (a) the "ordinary" unicast routes or (b) a special set of routes that are used exclusively for upstream multicast hop selection is a matter of policy. How that policy is chosen, deployed, or implemented is outside the scope of this document. In the following, we will simply refer to the set of routes that are used for upstream multicast hop selection, the "Eligible UMH routes", with no presumptions about the policy by which this set of routes was chosen.
ただし、場合によっては、CESは、上流のマルチキャストホップ選択の目的でのみ使用され、ユニキャストルーティングにはまったく使用されていない特別なルートセットをPESに分配している場合があります。たとえば、BGPがCE-PEユニキャストルーティングプロトコルである場合、CESは後続のアドレスファミリ識別子2（SAFI 2）を使用して、アップストリームマルチキャストホップ選択のために使用される特別なルートセットを配布している可能性があります。 。 OSPF [OSPF]がCE-PEルーティングプロトコルである場合、CEはMT-ID（マルチトポロジ識別子）[OSPF-MT]を使用して、使用する特別なルートセットを分散する場合があります。上流のマルチキャストホップ選択。 CEがこれらのメカニズムの1つを使用して、上流のマルチキャストホップ選択にのみ使用する特別なルートセットのPEに分布する場合、[MVPN-BGP]に記載されているように、これらのルートはSAFI 129を使用してPESに分布します。上流のマルチキャストホップ選択に使用されるルートが（a）「通常の」ユニキャストルートであるか、（b）アップストリームマルチキャストホップ選択にのみ使用される特別なルートのセットは、ポリシーの問題です。そのポリシーの選択、展開、または実装の方法は、このドキュメントの範囲外です。以下では、このルートのセットが選択されたポリシーに関する推定はありませんが、上流のマルチキャストホップ選択に使用されるルートのセットである「適格なUMHルート」を参照します。
Every route that is eligible for UMH selection SHOULD carry a VRF Route Import Extended Community [MVPN-BGP]. However, if BGP is used to distribute C-multicast routing information, or if the route is from a VRF that belongs to a multi-AS VPN as described in option b of Section 10 of [RFC4364], then the route MUST carry a VRF Route Import Extended Community. This attribute identifies the PE that originated the route.
UMH選択の対象となるすべてのルートは、VRFルートインポート拡張コミュニティ[MVPN-BGP]を搭載する必要があります。ただし、BGPがC-Multicastルーティング情報を配布するために使用される場合、または[RFC4364]のセクション10のオプションBで説明されているように、ルートがMulti-AS VPNに属するVRFからである場合、ルートはVRFを運ぶ必要があります。ルートインポート拡張コミュニティ。この属性は、ルートを発信したPEを識別します。
If BGP is used for carrying C-multicast routes, OR if "Segmented inter-AS Tunnels" are used, then every UMH route MUST also carry a Source AS Extended Community [MVPN-BGP].
BGPがC-Multicastルートを運ぶために使用される場合、または「セグメント化されたトンネル」を使用する場合、すべてのUMHルートも拡張コミュニティ[MVPN-BGP]としてソースを運ぶ必要があります。
These two attributes are used in the upstream multicast hop selection procedures described below.
これらの2つの属性は、以下で説明する上流のマルチキャストホップ選択手順で使用されます。
The first step in selecting the upstream multicast hop for a given C-root is to select the Upstream PE router for that C-root.
特定のCルートのアップストリームマルチキャストホップを選択する最初のステップは、そのCルートのアップストリームPEルーターを選択することです。
The PE that received the C-Join message from a CE looks in the VRF corresponding to the interfaces over which the C-Join was received. It finds the Eligible UMH route that is the best match for the C-root specified in that C-Join. Call this the "Installed UMH Route".
CEからC結合メッセージを受信したPEは、C-Joinが受信されたインターフェイスに対応するVRFを検索します。そのC結合で指定されたCルートに最適な適格なUMHルートが見つかります。これを「インストールされたUMHルート」と呼びます。
Note that the outgoing interface of the Installed UMH Route may be one of the interfaces associated with the VRF, in which case the upstream multicast hop is a CE and the route to the C-root is not across the VPN backbone.
インストールされたUMHルートの発信インターフェイスは、VRFに関連付けられたインターフェイスの1つである可能性があることに注意してください。この場合、上流のマルチキャストホップはCEであり、CルートへのルートはVPNバックボーン全体ではありません。
Consider the set of all VPN-IP routes that (a) are eligible to be imported into the VRF (as determined by their Route Targets), (b) are eligible to be used for upstream multicast hop selection, and (c) have exactly the same IP prefix (not necessarily the same RD) as the installed UMH route.
（a）VRFにインポートされる資格がある（ルートターゲットによって決定される）、（b）上流のマルチキャストホップ選択に使用する資格があり、（c）正確に使用されるすべてのVPN-IPルートのセットを考えてみましょう。インストールされているUMHルートと同じIPプレフィックス（必ずしも同じRDではありません）。
For each route in this set, determine the corresponding Upstream PE and Upstream RD. If a route has a VRF Route Import Extended Community, the route's Upstream PE is determined from it. If a route does not have a VRF Route Import Extended Community, the route's Upstream PE is determined from the route's BGP Next Hop. In either case, the Upstream RD is taken from the route's NLRI.
このセットの各ルートについて、対応するアップストリームPEとアップストリームRDを決定します。ルートにVRFルートが拡張されたコミュニティがインポートされている場合、ルートの上流のPEが決定されます。ルートにVRFルートインポートエクステンションコミュニティがない場合、ルートの上流PEはルートのBGP次のホップから決定されます。どちらの場合でも、上流のRDはルートのNLRIから取得されます。
This results in a set of triples of <route, Upstream PE, Upstream RD>.
これにより、<ルート、アップストリームPE、上流のRD>のトリプルのセットが得られます。
Call this the "UMH Route Candidate Set". Then, the PE MUST select a single route from the set to be the "Selected UMH Route". The corresponding Upstream PE is known as the "Selected Upstream PE", and the corresponding Upstream RD is known as the "Selected Upstream RD".
これを「UMHルート候補セット」と呼びます。次に、PEはセットから単一のルートを「選択されたUMHルート」にする必要があります。対応する上流のPEは「選択された上流のPE」として知られており、対応する上流のRDは「選択されたアップストリームRD」として知られています。
There are several possible procedures that can be used by a PE to select a single route from the candidate set.
PEで使用して、候補セットから単一のルートを選択できる手順がいくつかあります。
The default procedure, which MUST be implemented, is to select the route whose corresponding Upstream PE address is numerically highest, where a 32-bit IP address is treated as a 32-bit unsigned integer. Call this the "default Upstream PE selection". For a given C-root, provided that the routing information used to create the candidate set is stable, all PEs will have the same default Upstream PE selection. (Though different default Upstream PE selections may be chosen during a routing transient.)
実装する必要があるデフォルトの手順は、対応する上流のPEアドレスが数値的に最も高く、32ビットのIPアドレスが32ビットの符号なし整数として扱われるルートを選択することです。これを「デフォルトのアップストリームPE選択」と呼びます。候補セットの作成に使用されるルーティング情報が安定している場合、特定のC-Rootの場合、すべてのPESには同じデフォルトの上流PE選択があります。（さまざまなデフォルトの上流PE選択は、ルーティングの過渡期に選択される場合があります。）
An alternative procedure that MUST be implemented, but which is disabled by default, is the following. This procedure ensures that, except during a routing transient, each PE chooses the same Upstream PE for a given combination of C-root and C-G.
実装する必要があるがデフォルトで無効にされている代替手順は、次のものです。この手順により、ルーティングの過渡期間中を除き、各PEは、C-RootとC-Gの特定の組み合わせに対して同じ上流のPEを選択することが保証されます。
1. The PEs in the candidate set are numbered from lowest to highest IP address, starting from 0.
1. 候補セットのPESは、0から始まる最低のIPアドレスから最高のIPアドレスまで番号が付けられています。
2. The following hash is performed:
2. 次のハッシュが実行されます。
- A bytewise exclusive-or of all the bytes in the C-root address and the C-G address is performed.
- C-RootアドレスとC-Gアドレスのすべてのバイトの排他的またはC-gアドレスが実行されます。
- The result is taken modulo n, where n is the number of PEs in the candidate set. Call this result N.
- 結果はmodulo nを取得します。ここで、nは候補セットのPEの数です。この結果nを呼び出します。
The Selected Upstream PE is then the one that appears in position N in the list of step 1.
選択した上流のPEは、ステップ1のリストに位置nに表示されるものです。
Other hashing algorithms are allowed as well, but not required.
他のハッシュアルゴリズムも許可されていますが、必要ありません。
The alternative procedure allows a form of "equal cost load balancing". Suppose, for example, that from egress PEs PE3 and PE4, source C-S can be reached, at equal cost, via ingress PE PE1 or ingress PE PE2. The load balancing procedure makes it possible for PE1 to be the ingress PE for (C-S,C-G1) data traffic while PE2 is the ingress PE for (C-S,C-G2) data traffic.
代替手順では、「等しいコスト負荷分散」の形式が可能になります。たとえば、出力PES PE3およびPE4から、ソースC-Sに到達できると仮定します。負荷分散手順により、PE1は（C-S、C-G1）データトラフィックの侵入PEになることができ、PE2は（C-S、C-G2）データトラフィックの侵入PEです。
Another procedure, which SHOULD be implemented, is to use the Installed UMH Route as the Selected UMH Route. If this procedure is used, the result is likely to be that a given PE will choose the Upstream PE that is closest to it, according to the routing in the SP backbone. As a result, for a given C-root, different PEs may choose different Upstream PEs. This is useful if the C-root is an anycast address, and can also be useful if the C-root is in a multihomed site (i.e., a site that is attached to multiple PEs). However, this procedure is more likely to lead to steady state duplication of traffic unless (a) PEs discard data traffic that arrives from the "wrong" Upstream PE or (b) data traffic is carried only in non-aggregated S-PMSIs. This issue is discussed at length in Section 9.
実装する必要があるもう1つの手順は、選択したUMHルートとしてインストールされているUMHルートを使用することです。この手順を使用すると、SPバックボーンのルーティングに応じて、特定のPEがそれに最も近い上流のPEを選択する可能性があります。その結果、特定のCルートの場合、異なるPEが異なる上流のPEを選択する場合があります。これは、C-RootがAnycastアドレスである場合に便利であり、C-Rootがマルチホームサイト（つまり、複数のPEに接続されているサイト）にある場合にも役立ちます。ただし、この手順は、（a）「間違った」上流のPEまたは（b）データトラフィックが非凝集S-PMSIでのみ運ばれるデータトラフィックを破棄しない限り、トラフィックの定常状態の複製につながる可能性が高くなります。この問題は、セクション9で詳細に説明されています。
General policy-based procedures for selecting the UMH route are allowed but not required, and they are not further discussed in this specification.
UMHルートを選択するための一般的なポリシーベースの手順は許可されていますが、必須ではありません。これらは、この仕様ではさらに議論されていません。
In certain cases, the Selected Upstream Multicast Hop is the same as the Selected Upstream PE. In other cases, the Selected Upstream Multicast Hop is the ASBR that is the BGP Next Hop of the Selected UMH Route.
特定の場合、選択したアップストリームマルチキャストホップは、選択したアップストリームPEと同じです。他の場合、選択されたアップストリームマルチキャストホップは、選択したUMHルートのBGP次のホップであるASBRです。
If the Selected Upstream PE is in the local AS, then the Selected Upstream PE is also the Selected Upstream Multicast Hop. This is the case if any of the following conditions holds:
選択したアップストリームPEがローカルASにある場合、選択したアップストリームPEは選択されたアップストリームマルチキャストホップでもあります。これは、次の条件のいずれかが当てはまる場合です。
- The Selected UMH Route has a Source AS Extended Community, and the Source AS is the same as the local AS,
- 選択したUMHルートには、拡張コミュニティとしてソースがあり、ソースはローカルと同じです。
- The Selected UMH Route does not have a Source AS Extended Community, but the route's BGP Next Hop is the same as the Upstream PE.
- 選択したUMHルートには、拡張コミュニティとしてソースがありませんが、ルートのBGP次のホップは上流のPEと同じです。
Otherwise, the Selected Upstream Multicast Hop is an ASBR. The method of determining just which ASBR it is depends on the particular inter-AS signaling method being used (PIM or BGP) and on whether segmented or non-segmented inter-AS tunnels are used. These details are presented in later sections.
それ以外の場合、選択したアップストリームマルチキャストホップはASBRです。どのASBRが使用されている特定のAS間のシグナル伝達方法（PIMまたはBGP）に依存するか、およびセグメント化されていないトンネルまたは非セグメント化されていないトンネルに依存する方法。これらの詳細は、後のセクションに示されています。
When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat the MI-PMSI as a LAN interface and form full PIM adjacencies with each other over that LAN interface.
MVPNがMi-PMSIを使用すると、そのMVPNのCインスタンスはMi-PMSIをLANインターフェイスとして扱い、そのLANインターフェイスで互いに完全なPIM隣接を形成できます。
The use of PIM when an MI-PMSI is not in use is outside the scope of this document.
Mi-PMSIが使用されていない場合のPIMの使用は、このドキュメントの範囲外です。
To form full PIM adjacencies, the PEs execute the standard PIM procedures on the LAN interface, including the generation and processing of PIM Hello, Join/Prune, Assert, DF (Designated Forwarder) election, and other PIM control messages. These are executed independently for each C-instance. PIM "Join suppression" SHOULD be enabled.
完全なPIM隣接を形成するために、PESは、PIM Hello、Join/Prune、Assert、DF（指定されたフォワーダー）選挙、およびその他のPIM制御メッセージの生成と処理など、LANインターフェイス上の標準PIMプロシージャを実行します。これらは、各Cインスタンスに対して独立して実行されます。PIM「抑制の結合」を有効にする必要があります。
All IPv4 PIM C-instance control packets of a particular MVPN are addressed to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address and transmitted over the MI-PMSI of that MVPN. While in transit in the P-network, the packets are encapsulated as required for the particular kind of P-tunnel that is being used to instantiate the
特定のMVPNのすべてのIPv4 PIM Cインスタンス制御パケットは、All-PIM-Routers（224.0.0.13）IP宛先アドレスにアドレス指定され、そのMVPNのMi-PMSIに送信されます。Pネットワークでの輸送中に、パケットは、インスタンス化するために使用されている特定の種類のPトンネルに必要に応じてカプセル化されています
MI-PMSI. Thus, the C-instance control packets are not processed by the P routers, and MVPN-specific PIM routes can be extended from site to site without appearing in the P routers.
mi-pmsi。したがって、Cインスタンス制御パケットはPルーターによって処理されず、MVPN固有のPIMルートは、Pルーターに表示されることなくサイトからサイトに拡張できます。
The handling of IPv6 PIM C-instance control packets will be specified in a follow-on document.
IPv6 PIM C-Instanceコントロールパケットの処理は、後続ドキュメントで指定されます。
As specified in Section 5.1.2, when PIM is being used to distribute C-multicast routing information, any PE distributing VPN-IP routes that are eligible for use as UMH routes SHOULD include a VRF Route Import Extended Community with each route. For a given VRF, the Global Administrator field of the VRF Route Import Extended Community MUST be set to the same IP address that the PE places in the IP source address field of the PE-PE PIM control messages it originates from that VRF.
セクション5.1.2で指定されているように、PIMがC-Multicastルーティング情報を配布するために使用されている場合、UMHルートとして使用する資格のあるVPN-IPルートを配布するPEは、各ルートでVRFルートインポートエクステンションコミュニティを含める必要があります。特定のVRFの場合、VRFルートインポート拡張コミュニティのグローバル管理者フィールドは、PEがそのVRFから発信するPE-PE PIMコントロールメッセージのIPソースアドレスフィールドにPEが配置するのと同じIPアドレスに設定する必要があります。
Note that BSR (Bootstrap Router Mechanism for PIM) [BSR] messages are treated the same as PIM C-instance control packets, and BSR processing is regarded as an integral part of the PIM C-instance processing.
BSR（PIMのブートストラップルーターメカニズム）[BSR]メッセージはPIM Cインスタンス制御パケットと同じで扱われ、BSR処理はPIM Cインスタンス処理の不可欠な部分と見なされることに注意してください。
Although the MI-PMSI is treated by PIM as a LAN interface, unicast routing is NOT run over it, and there are no unicast routing adjacencies over it. Therefore, it is necessary to specify special procedures for determining when the MI-PMSI is to be regarded as the "RPF Interface" for a particular C-address.
Mi-PMSIはPIMによってLANインターフェイスとして扱われますが、ユニキャストルーティングは実行されず、ユニキャストルーティングの隣接はありません。したがって、Mi-PMSIが特定のCアドレスの「RPFインターフェイス」と見なされる時期を決定するための特別な手順を指定する必要があります。
The PE follows the procedures of Section 5.1 to determine the Selected UMH Route. If that route is NOT a VPN-IP route learned from BGP as described in [RFC4364], or if that route's outgoing interface is one of the interfaces associated with the VRF, then ordinary PIM procedures for determining the RPF interface apply.
PEはセクション5.1の手順に従って、選択したUMHルートを決定します。そのルートが[RFC4364]で説明されているようにBGPから学習したVPN-IPルートではない場合、またはそのルートの発信インターフェイスがVRFに関連付けられたインターフェイスの1つである場合、RPFインターフェイスを決定するための通常のPIM手順が適用されます。
However, if the Selected UMH Route is a VPN-IP route whose outgoing interface is not one of the interfaces associated with the VRF, then PIM will consider the RPF interface to be the MI-PMSI associated with the VPN-specific PIM instance.
ただし、選択したUMHルートが、発信インターフェイスがVRFに関連付けられたインターフェイスの1つではないVPN-IPルートである場合、PIMはRPFインターフェイスがVPN固有のPIMインスタンスに関連付けられたMi-PMSIであると見なします。
Once PIM has determined that the RPF interface for a particular C-root is the MI-PMSI, it is necessary for PIM to determine the "RPF neighbor" for that C-root. This will be one of the other PEs that is a PIM adjacency over the MI-PMSI. In particular, it will be the "Selected Upstream PE", as defined in Section 5.1.
PIMが特定のCルートのRPFインターフェイスがMi-PMSIであると判断すると、PIMがそのCルートの「RPF隣接」を決定する必要があります。これは、Mi-PMSI上のPIM隣接である他のPESの1つになります。特に、セクション5.1で定義されているように、それは「選択された上流のPE」になります。
It is possible to use BGP to carry C-multicast routing information from PE to PE, dispensing entirely with the transmission of C-Join/Prune messages from PE to PE. This section describes the procedures for carrying intra-AS multicast routing information. Inter-AS procedures are described in Section 8. The complete specification of both sets of procedures and of the encodings can be found in [MVPN-BGP].
BGPを使用してC-Multicastルーティング情報をPEからPEへのルーティング情報を運ぶことができ、PEからPEへのC結合/プルーンメッセージの送信を完全に分配することができます。このセクションでは、イントラASマルチキャストルーティング情報を運ぶ手順について説明します。AS間の手順については、セクション8で説明します。両方の手順とエンコーディングの両方の完全な仕様は、[MVPN-BGP]に記載されています。
The MCAST-VPN address family is used for this purpose. MCAST-VPN routes used for the purpose of carrying C-multicast routing information are distinguished from those used for the purpose of carrying auto-discovery information by means of a "route type" field that is encoded into the NLRI. The following information is required in BGP to advertise the MVPN routing information. The NLRI contains the following:
MCAST-VPNアドレスファミリは、この目的に使用されます。c-multicastルーティング情報を運ぶ目的で使用されるmcast-vpnルートは、NLRIにエンコードされた「ルートタイプ」フィールドを使用して、自動発見情報を運ぶ目的で使用されるものと区別されます。MVPNルーティング情報を宣伝するために、BGPでは次の情報が必要です。NLRIには次のものが含まれています。
- The type of C-multicast route
- C-Multicastルートのタイプ
There are two types:
2つのタイプがあります。
* source tree join
* ソースツリー結合
* shared tree join
* 共有ツリー結合
- The C-group address
- Cグループアドレス
- The C-source address (In the case of a shared tree join, this is the address of the C-RP.)
- Cソースアドレス（共有ツリーが結合された場合、これはC-RPのアドレスです。）
- The Selected Upstream RD corresponding to the C-root address (determined by the procedures of Section 5.1).
- C-ROOTアドレスに対応する選択されたアップストリームRD（セクション5.1の手順で決定）。
Whenever a C-multicast route is sent, it must also carry the Selected Upstream Multicast Hop corresponding to the C-root address (determined by the procedures of Section 5.1). The Selected Upstream Multicast Hop must be encoded as part of a Route Target Extended Community to facilitate the optional use of filters that can prevent the distribution of the update to BGP speakers other than the Upstream Multicast Hop. See Section 10.1.3 of [MVPN-BGP] for the details.
C-Multicastルートが送信されるときはいつでも、C-Rootアドレスに対応する選択されたアップストリームマルチキャストホップも携帯する必要があります（セクション5.1の手順で決定）。選択したアップストリームマルチキャストホップは、上流のマルチキャストホップ以外のBGPスピーカーへの更新の分布を防ぐことができるフィルターのオプションの使用を容易にするために、ルートターゲット拡張コミュニティの一部としてエンコードする必要があります。詳細については、[MVPN-BGP]のセクション10.1.3を参照してください。
There is no C-multicast route corresponding to the PIM function of pruning a source off the shared tree when a PE switches from a (C-*,C-G) tree to a (C-S,C-G) tree. Section 9 of this document
PEが（c - *、c-g）ツリーから（c-s、c-g）ツリーに切り替わるときに、共有ツリーからソースを剪定するPIM関数に対応するCマルチカストルートはありません。このドキュメントのセクション9
specifies a mandatory procedure that ensures that if any PE joins a (C-S,C-G) source tree, all other PEs that have joined or will join the (C-*,C-G) shared tree will also join the (C-S,C-G) source tree.
PEが（C-S、C-G）ソースツリーに結合する場合、（C-*、C-G）共有ツリーに結合または結合する他のすべてのPEが（C-S、C-G）ソースツリーにも参加することを保証する必須手順を指定します。。
This eliminates the need for a C-multicast route that prunes C-S off the (C-*,C-G) shared tree when switching from (C-*,C-G) to (C-S,C-G) tree.
これにより、（c - *、c-g）から（c-s、c-g）ツリーに切り替えるときに（c - *、c-g）共有ツリーからc-sをプルネするcマルチキャストルートの必要性が排除されます。
Note that the upstream multicast hop is NOT part of the NLRI in the C-multicast BGP routes. This means that if several PEs join the same C-tree, the BGP routes they distribute to do so are regarded by BGP as comparable routes, and only one will be installed. If a route reflector is being used, this further means that the PE that is used to reach the C-source will know only that one or more of the other PEs have joined the tree, but it won't know which one. That is, this BGP update mechanism does not provide "explicit tracking". Explicit tracking is not provided by default because it increases the amount of state needed and thus decreases scalability. Also, as constructing the C-PIM messages to send "upstream" for a given tree does not depend on knowing all the PEs that are downstream on that tree, there is no reason for the C-multicast route type updates to provide explicit tracking.
上流のマルチキャストホップは、CマルチキャストBGPルートのNLRIの一部ではないことに注意してください。これは、いくつかのPEが同じCトリーに参加する場合、彼らがそうするために配布するBGPルートがBGPによって同等のルートと見なされ、1つだけがインストールされることを意味します。ルートリフレクターが使用されている場合、これはさらに、Cソースに到達するために使用されるPEが、他の1つ以上のPEがツリーに参加したことのみを知っていることを意味しますが、どれがわかりません。つまり、このBGP更新メカニズムは「明示的な追跡」を提供しません。明示的な追跡は、必要な状態の量を増やし、したがってスケーラビリティを低下させるため、デフォルトでは提供されません。また、特定のツリーに「上流」を送信するためのC-PIMメッセージを構築することは、そのツリーの下流のすべてのPEを知ることに依存しないため、C-Multicastルートタイプの更新が明示的な追跡を提供する理由はありません。
There are some cases in which explicit tracking is necessary in order for the PEs to set up certain kinds of P-trees. There are other cases in which explicit tracking is desirable in order to determine how to optimally aggregate multicast flows onto a given aggregate tree. As these functions have to do with the setting up of infrastructure in the P-network, rather than with the dissemination of C-multicast routing information, any explicit tracking that is necessary is handled by sending a particular type of A-D route known as "Leaf A-D routes".
PESが特定の種類のPツリーをセットアップするために明示的な追跡が必要な場合があります。特定の集合ツリーにマルチキャストフローを最適に集約する方法を決定するために、明示的な追跡が望ましい他のケースがあります。これらの関数は、Cマルチキャストルーティング情報の普及ではなく、Pネットワークのインフラストラクチャのセットアップに関係しているため、必要な明示的な追跡は、「リーフ」として知られる特定のタイプのA-Dルートを送信することによって処理されます。A-Dルート」。
Whenever a PE sends an A-D route with a PMSI Tunnel attribute, it can set a bit in the PMSI Tunnel attribute indicating "Leaf Information Required". A PE that installs such an A-D route MUST respond by generating a Leaf A-D route, indicating that it needs to join (or be joined to) the specified PMSI Tunnel. Details can be found in [MVPN-BGP].
PEがPMSIトンネル属性を持つA-Dルートを送信するたびに、「必要な葉情報」を示すPMSIトンネル属性に少し設定できます。このようなA-DルートをインストールするPEは、リーフA-Dルートを生成して応答する必要があります。これは、指定されたPMSIトンネルに結合（または結合する）必要があることを示します。詳細は[MVPN-BGP]にあります。
A PE removes itself from a C-multicast tree (shared or source) by withdrawing the corresponding BGP Update.
PEは、対応するBGPアップデートを撤回することにより、C-Multicastツリー（共有またはソース）からそれ自体を削除します。
If a PE has pruned a C-source from a shared C-multicast tree, and it needs to "unprune" that source from that tree, it does so by withdrawing the route that pruned the source from the tree.
PEが共有C-Multicastツリーからcソースを剪定し、そのツリーからそのソースを「整理」する必要がある場合、ツリーからソースを剪定するルートを引き出すことにより、そうします。
BGP does not provide a method for carrying the control information of BSR packets received by a PE from a CE. BSR is supported by transmitting the BSR control messages from one PE in an MVPN to all the other PEs in that MVPN.
BGPは、CEからPEが受け取ったBSRパケットの制御情報を運ぶ方法を提供しません。BSRは、MVPNの1つのPEからそのMVPNの他のすべてのPEにBSR制御メッセージを送信することでサポートされています。
When a PE needs to transmit a BSR message for a particular MVPN to other PEs, it must put its own IP address into the BSR message as the IP source address. As specified in Section 5.1.2, when a PE distributes VPN-IP routes that are eligible for use as UMH routes, the PE MUST include a VRF Route Import Extended Community with each route. For a given MVPN, a single such IP address MUST be used, and that same IP address MUST be used as the source address in all BSR packets that the PE transmits to other PEs.
PEが特定のMVPNのBSRメッセージを他のPEに送信する必要がある場合、IPソースアドレスとして独自のIPアドレスをBSRメッセージに入れる必要があります。セクション5.1.2で指定されているように、PEがUMHルートとして使用できるVPN-IPルートを配布する場合、PEには各ルートでVRFルートインポートエクステンションコミュニティを含める必要があります。特定のMVPNの場合、そのようなIPアドレスを1つ使用する必要があり、その同じIPアドレスを他のPEに送信するすべてのBSRパケットのソースアドレスとして使用する必要があります。
The BSR message may be transmitted over any PMSI that will deliver the message to all the other PEs in the MVPN. If no such PMSI has been instantiated yet, then an appropriate P-tunnel must be advertised, and the C-flow whose C-source address is the address of the PE itself, and whose multicast group is ALL-PIM-ROUTERS (224.0.0.13), must be bound to it. This can be done using the procedures described in Sections 7.3 and 7.4. Note that this is NOT meant to imply that the other PIM control packets from the PIM C-instance are to be transmitted to the other PEs.
BSRメッセージは、MVPNの他のすべてのPEにメッセージを配信するPMSIを介して送信される場合があります。そのようなPMSIがまだインスタンス化されていない場合、適切なPトンネルを宣伝する必要があり、C-SourceアドレスがPE自体のアドレスであり、マルチキャストグループがAll-PIM-Routers（224.0のアドレスです。0.13）、それに拘束する必要があります。これは、セクション7.3および7.4で説明されている手順を使用して実行できます。これは、PIM Cインスタンスからの他のPIM制御パケットが他のPEに送信されることを意味することを意図していないことに注意してください。
When a PE receives a BSR message for a particular MVPN from some other PE, the PE accepts the message only if the IP source address in that message is the Selected Upstream PE (see Section 5.1.3) for the IP address of the Bootstrap router. Otherwise, the PE simply discards the packet. If the PE accepts the packet, it does normal BSR processing on it, and it may forward a BSR message to one or more CEs as a result.
PEが他のPEから特定のMVPNのBSRメッセージを受信すると、PEは、そのメッセージのIPソースアドレスがBootstrapルーターのIPアドレスの選択されたアップストリームPE（セクション5.1.3を参照）である場合にのみメッセージを受け入れます。。それ以外の場合、PEは単にパケットを破棄します。PEがパケットを受け入れると、通常のBSR処理を行い、結果としてBSRメッセージを1つ以上のCESに転送する可能性があります。
This section provides the procedures for using P-tunnels to instantiate a PMSI. It describes the procedures for setting up and maintaining the P-tunnels as well as for sending and receiving C-data and/or C-control messages on the P-tunnels. However, procedures for binding particular C-flows to particular P-tunnels are discussed in Section 7.
このセクションでは、Pタンネルを使用してPMSIをインスタンス化する手順を示します。Pタンネルのセットアップと保守、およびPタンネルでのC-DATAおよび/またはC-Controlメッセージの送信と受信の手順について説明します。ただし、特定のCフローを特定のPタンネルに結合する手順については、セクション7で説明します。
PMSIs can be instantiated either by P-multicast trees or by PE-PE unicast tunnels. In the latter case, the PMSI is said to be instantiated by "ingress replication".
PMSIは、P-MulticastツリーまたはPE-PEユニキャストトンネルによってインスタンス化できます。後者の場合、PMSIは「イングレスレプリケーション」によってインスタンス化されていると言われています。
This specification supports a number of different methods for setting up P-multicast trees: these are detailed below. A P-tunnel may support a single VPN (a non-aggregated P-multicast tree) or multiple VPNs (an aggregated P-multicast tree).
この仕様は、P-Multicastツリーをセットアップするためのさまざまな方法をサポートしています。これらの詳細については、以下に詳しく説明しています。Pトンネルは、単一のVPN（凝集していないP-マルチカストツリー）または複数のVPN（集約されたP-マルチカストツリー）をサポートする場合があります。
When a PE is provisioned to have one or more VRFs that provide MVPN support, the PE announces its MVPN membership information using Intra-AS I-PMSI A-D routes, as discussed in Section 4 and detailed in Section 9.1.1 of [MVPN-BGP]. (Under certain conditions, detailed in [MVPN-BGP], the Intra-AS I-PMSI A-D route may be omitted.)
PEがMVPNサポートを提供する1つ以上のVRFを提供するようにプロビジョニングされた場合、PEは、セクション4で説明し、[MVPN-BGPのセクション9.1.1で詳述されているように、INTRA-AS I-PMSI A-Dルートを使用してMVPNメンバーシップ情報を発表します。]。（[MVPN-BGP]で詳述されている特定の条件下では、INTRA-AS I-PMSI A-Dルートが省略される場合があります。）
Generally, the Intra-AS I-PMSI A-D route will have a PMSI Tunnel attribute that identifies a P-tunnel that is being used to instantiate the I-PMSI. Section 9.1.1 of [MVPN-BGP] details certain conditions under which the PMSI Tunnel attribute may be omitted (or in which a PMSI Tunnel attribute with the "no tunnel information present" bit may be sent).
一般に、INTRA-AS I-PMSI A-Dルートには、I-PMSIのインスタンス化に使用されているPトンネルを識別するPMSIトンネル属性があります。[MVPN-BGP]のセクション9.1.1は、PMSIトンネル属性が省略される可能性がある特定の条件（または、「トンネル情報なしの存在する」ビットを含むPMSIトンネル属性が送信される可能性がある）を詳述しています。
As a special case, when (a) C-PIM control messages are to be sent through an MI-PMSI and (b) the MI-PMSI is instantiated by a P-tunnel technique for which each PE needs to know only a single P-tunnel identifier per VPN, then the use of the Intra-AS I-PMSI A-D routes MAY be omitted, and static configuration of the tunnel identifier used instead. However, this is not recommended for long-term use, and in all other cases, the Intra-AS I-PMSI A-D routes MUST be used.
特別なケースとして、（a）C-PIM制御メッセージがMi-PMSIを介して送信される場合、（b）Mi-PMSIは、各PEが単一のpのみを知る必要があるpターンネル技術によってインスタンス化されます。-VPNあたりのトンネル識別子、次にI-PMSI A-Dルートの使用を省略し、代わりに使用するトンネル識別子の静的構成を省略できます。ただし、これは長期的な使用には推奨されません。他のすべての場合、IPS-AS I-PMSI A-Dルートを使用する必要があります。
The PMSI Tunnel attribute MAY contain an upstream-assigned MPLS label, assigned by the PE originating the Intra-AS I-PMSI A-D route. If this label is present, the P-tunnel can be carrying data from several MVPNs. The label is used on the data packets traveling through the tunnel to identify the MVPN to which those data packets belong. (The specified label identifies the packet as belonging to the MVPN that is identified by the RTs of the Intra-AS I-PMSI A-D route.)
PMSIトンネル属性には、I-PMSI A-Dルートを発信するPEによって割り当てられたアップストリーム割り当てのMPLSラベルが含まれている場合があります。このラベルが存在する場合、PトンネルはいくつかのMVPNからデータを運ぶことができます。ラベルは、トンネルを通過するデータパケットで使用され、それらのデータパケットが属するMVPNを識別します。（指定されたラベルは、Intra-As I-PMSI A-DルートのRTによって識別されるMVPNに属するパケットを識別します。）
See Section 12.2 for details on how to place the label in the packet's label stack.
パケットのラベルスタックにラベルを配置する方法の詳細については、セクション12.2を参照してください。
The Intra-AS I-PMSI A-D route may contain a "PE Distinguisher Labels" attribute. This contains a set of bindings between upstream-assigned labels and PE addresses. The PE that originated the route may use this to bind an upstream-assigned label to one or more of the other PEs that belong to the same MVPN. The way in which PE Distinguisher Labels are used is discussed in Sections 6.4.1, 6.4.3, 11.2.2, and 12.3. Other uses of the PE Distinguisher Labels attribute are outside the scope of this document.
Intra-AS I-PMSI A-Dルートには、「PE違いラベル」属性が含まれる場合があります。これには、上流のラベルとPEアドレスの間のバインディングのセットが含まれています。ルートを発信したPEは、これを使用して、同じMVPNに属する他のPEの1つ以上に上流のラベルを結合する場合があります。PEの違いラベルを使用する方法については、セクション6.4.1、6.4.3、11.2.2、および12.3で説明します。PE Distiminger Labels属性のその他の使用は、このドキュメントの範囲外です。
The action to be taken when a PE receives an Intra-AS I-PMSI A-D route for a particular MVPN depends on the particular P-tunnel technology that is being used by that MVPN. If the P-tunnel technology requires tunnels to be built by means of receiver-initiated joins, the PE SHOULD join the tunnel immediately.
PEが特定のMVPNのI-PMSI A-Dルートを受け取ったときに実行されるアクションは、そのMVPNで使用されている特定のPトンネルテクノロジーに依存します。P-Tunnelテクノロジーでは、受信機が開始する結合によってトンネルを構築する必要がある場合、PEはすぐにトンネルに参加する必要があります。
This situation is discussed in Section 7.
この状況については、セクション7で説明します。
When a P-multicast tree is shared across multiple MVPNs, it is termed an "Aggregate Tree". The procedures described in this document allow a single SP multicast tree to be shared across multiple MVPNs. Unless otherwise specified, P-multicast tree technology supports aggregation.
P-Multicastツリーが複数のMVPNで共有されると、「集計ツリー」と呼ばれます。このドキュメントで説明されている手順により、単一のSPマルチキャストツリーを複数のMVPNで共有できます。特に指定されていない限り、P-Multicast Tree Technologyは集約をサポートします。
All procedures that are specific to multi-MVPN aggregation are OPTIONAL and are explicitly pointed out.
マルチMVPN集約に固有のすべての手順はオプションであり、明示的に指摘されています。
Aggregate Trees allow a single P-multicast tree to be used across multiple MVPNs so that state in the SP core grows per set of MVPNs and not per MVPN. Depending on the congruence of the aggregated MVPNs, this may result in trading off optimality of multicast routing.
骨材のツリーにより、複数のMVPNで単一のPマルチキャストツリーを使用できるようにするため、SPコアの状態はMVPNのセットごとに成長し、MVPNごとではありません。集約されたMVPNの一致に応じて、これにより、マルチキャストルーティングの最適性を取引する可能性があります。
An Aggregate Tree can be used by a PE to provide a UI-PMSI or MI-PMSI service for more than one MVPN. When this is the case, the Aggregate Tree is said to have an inclusive mapping.
総ツリーは、PEで使用して、複数のMVPNでUI-PMSIまたはMI-PMSIサービスを提供できます。この場合、凝集ツリーには包括的なマッピングがあると言われています。
BGP MVPN membership discovery (Section 4) allows a PE to determine the different Aggregate Trees that it should create and the MVPNs that should be mapped onto each such tree. The leaves of an Aggregate Tree are determined by the PEs, supporting aggregation, that belong to all the MVPNs that are mapped onto the tree.
BGP MVPNメンバーシップディスカバリー（セクション4）により、PEは作成すべき異なる骨材ツリーと、そのような各ツリーにマッピングするMVPNを決定できます。骨材の葉は、ツリーにマッピングされたすべてのMVPNに属する集約をサポートするPESによって決定されます。
If an Aggregate Tree is used to instantiate one or more S-PMSIs, then it may be desirable for the PE at the root of the tree to know which PEs (in its MVPN) are receivers on that tree. This enables the PE to decide when to aggregate two S-PMSIs, based on congruence (as discussed in the next section). Thus, explicit tracking may be required. Since the procedures for disseminating C-multicast routes do not provide explicit tracking, a type of A-D route known as a "Leaf A-D route" is used. The PE that wants to assign a particular C-multicast flow to a particular Aggregate Tree can send an A-D route, which elicits Leaf A-D routes from the PEs that need to receive that C-multicast flow. This provides the explicit tracking information needed to support the aggregation methodology discussed in the next section. For more details on Leaf A-D routes, please refer to [MVPN-BGP].
骨材のツリーを使用して1つ以上のS-PMSISをインスタンス化する場合、ツリーのルートのPEが（MVPN内）のPEがそのツリーの受信機であるかを知ることが望ましい場合があります。これにより、PEは一致に基づいて2つのS-PMSISをいつ集約するかを決定できます（次のセクションで説明します）。したがって、明示的な追跡が必要になる場合があります。C-Multicastルートを広める手順は明示的な追跡を提供しないため、「Leaf A-Dルート」として知られるA-Dルートのタイプが使用されます。特定のC-Multicastフローを特定の骨材ツリーに割り当てたいPEは、A-Dルートを送信できます。これにより、そのc-multicastフローを受信する必要があるPESから葉のA-Dルートが誘発されます。これにより、次のセクションで説明した集約方法論をサポートするために必要な明示的な追跡情報が提供されます。Leaf A-Dルートの詳細については、[MVPN-BGP]を参照してください。
This document does not specify the mandatory implementation of any particular set of rules for determining whether or not the PMSIs of two particular MVPNs are to be instantiated by the same Aggregate Tree. This determination can be made by implementation-specific heuristics, by configuration, or even perhaps by the use of offline tools.
このドキュメントでは、2つの特定のMVPNのPMSIが同じ集計ツリーによってインスタンス化されるかどうかを判断するための特定のルールセットの必須実装を指定しません。この決定は、実装固有のヒューリスティック、構成によって、またはおそらくオフラインツールの使用によって行うことができます。
It is the intention of this document that the control procedures will always result in all the PEs of an MVPN agreeing on the PMSIs that are to be used and on the tunnels used to instantiate those PMSIs.
このドキュメントの意図は、制御手順が常に使用されるPMSISおよびそれらのPMSIをインスタンス化するために使用されるトンネルに同意するMVPNのすべてのPESを常にもたらすことです。
This section discusses potential methodologies with respect to aggregation.
このセクションでは、集約に関する潜在的な方法論について説明します。
The "congruence" of aggregation is defined by the amount of overlap in the leaves of the customer trees that are aggregated on an SP tree. For Aggregate Trees with an inclusive mapping, the congruence depends on the overlap in the membership of the MVPNs that are aggregated on the tree. If there is complete overlap, i.e., all MVPNs have exactly the same sites, aggregation is perfectly congruent. As the overlap between the MVPNs that are aggregated reduces, i.e., the number of sites that are common across all the MVPNs reduces, the congruence reduces.
集約の「一致」は、SPツリーに集約されている顧客ツリーの葉のオーバーラップの量によって定義されます。包括的マッピングを備えた総ツリーの場合、合同はツリーに集約されているMVPNのメンバーシップのオーバーラップに依存します。完全なオーバーラップがある場合、つまり、すべてのMVPNがまったく同じサイトを持っている場合、集約は完全に一致します。集約されたMVPN間のオーバーラップが減少すると、つまり、すべてのMVPNで一般的なサイトの数が減少すると、合同が減少します。
If aggregation is done such that it is not perfectly congruent, a PE may receive traffic for MVPNs to which it doesn't belong. As the amount of multicast traffic in these unwanted MVPNs increases, aggregation becomes less optimal with respect to delivered traffic. Hence, there is a trade-off between reducing state and delivering unwanted traffic.
集約が完全に一致しないように行われた場合、PEはそれが属していないMVPNのトラフィックを受信する場合があります。これらの不要なMVPNのマルチキャストトラフィックの量が増加すると、供給されたトラフィックに関して集約が最適ではなくなります。したがって、状態を減らすことと不要なトラフィックの提供との間にはトレードオフがあります。
An implementation should provide knobs to control the congruence of aggregation. These knobs are implementation dependent. Configuring the percentage of sites that MVPNs must have in common to be aggregated is an example of such a knob. This will allow an SP to deploy aggregation depending on the MVPN membership and traffic profiles in its network. If different PEs or servers are setting up Aggregate Trees, this will also allow a service provider to engineer the maximum amount of unwanted MVPNs for which a particular PE may receive traffic.
実装は、集約の一致を制御するためのノブを提供する必要があります。これらのノブは実装に依存しています。MVPNが共通する必要があるサイトの割合を組み立てることは、そのようなノブの例です。これにより、SPはMVPNメンバーシップとそのネットワーク内のトラフィックプロファイルに応じて集約を展開できます。異なるPESまたはサーバーが総ツリーをセットアップしている場合、これにより、サービスプロバイダーが特定のPEがトラフィックを受信できる不要なMVPNの最大量を設計することもできます。
If a P-multicast tree is associated with only one MVPN, determining the P-multicast tree on which a packet was received is sufficient to determine the packet's MVPN. All that the egress PE needs to know is the MVPN with which the P-multicast tree is associated.
P-Multicastツリーが1つのMVPNのみに関連付けられている場合、パケットのMVPNを決定するにはパケットが受信されたP-Multicastツリーを決定するだけで十分です。出口PEが知っておく必要があるのは、P-Multicastツリーが関連付けられているMVPNだけです。
When multiple MVPNs are aggregated onto one P-multicast tree, determining the tree over which the packet is received is not sufficient to determine the MVPN to which the packet belongs. The packet must also carry some demultiplexing information to allow the egress PEs to determine the MVPN to which the packet belongs. Since the packet has been multicast through the P-network, any given demultiplexing value must have the same meaning to all the egress PEs. The demultiplexing value is a MPLS label that corresponds to the multicast VRF to which the packet belongs. This label is placed by the ingress PE immediately beneath the P-multicast tree header. Each of the egress PEs must be able to associate this MPLS label with the same MVPN. If downstream-assigned labels were used, this would require all the egress PEs in the MVPN to agree on a common label for the MVPN. Instead, the MPLS label is upstream-assigned [MPLS-UPSTREAM-LABEL]. The label bindings are advertised via BGP Updates originated by the ingress PEs.
複数のMVPNが1つのp-multicastツリーに集約されている場合、パケットが属するMVPNを決定するには、パケットの受信のツリーを決定するだけでは不十分です。また、パケットは、出力PEがパケットが属するMVPNを決定できるようにするために、いくつかの非gultiplexing情報を搭載する必要があります。パケットはPネットワークを介してマルチキャストであるため、特定の脱却値はすべての出力pesに対して同じ意味を持たなければなりません。 Demultiplexing値は、パケットが属するマルチキャストVRFに対応するMPLSラベルです。このラベルは、P-Multicast Treeヘッダーのすぐ下にあるIngress PEによって配置されます。各出口PESは、このMPLSラベルを同じMVPNに関連付けることができなければなりません。ダウンストリーム割り当てのラベルを使用した場合、これにはMVPNのすべての出力PEがMVPNの共通ラベルに同意する必要があります。代わりに、MPLSラベルはアップストリーム割り当て[MPLS-Upstream-Label]です。ラベルバインディングは、イングレスPESから発信されるBGPアップデートを介して宣伝されています。
This procedure requires each egress PE to support a separate label space for every other PE. The egress PEs create a forwarding entry for the upstream-assigned MPLS label, allocated by the ingress PE, in this label space. Hence, when the egress PE receives a packet over an Aggregate Tree, it first determines the tree over which the packet was received. The tree identifier determines the label space in which the upstream-assigned MPLS label lookup has to be performed.
この手順では、他のすべてのPEに個別のラベルスペースをサポートするために、各出力PEが必要です。出力PEは、このラベル空間に、イングレスPEによって割り当てられたアップストリーム割り当てのMPLSラベルの転送エントリを作成します。したがって、出力PEが骨材の上にパケットを受け取ると、最初にパケットが受信されたツリーを決定します。ツリー識別子は、上流で割り当てられたMPLSラベルルックアップを実行する必要があるラベル空間を決定します。
The same label space may be used for all P-multicast trees rooted at the same ingress PE or an implementation may decide to use a separate label space for every P-multicast tree.
同じラベルスペースは、同じ侵入PEに根付いたすべてのP-Multicastツリーに使用される場合があります。
A full specification of the procedures to support aggregation on shared trees or on MP2MP LSPs is outside the scope of this document.
共有ツリーまたはMP2MP LSPでの集約をサポートする手順の完全な仕様は、このドキュメントの範囲外です。
The encapsulation format is either MPLS or MPLS-in-something (e.g., MPLS-in-GRE [MPLS-IP]). When MPLS is used, this label will appear immediately below the label that identifies the P-multicast tree. When MPLS-in-GRE is used, this label will be the top MPLS label that appears when the GRE header is stripped off.
カプセル化形式は、MPLSまたはMPLS-in-someth（例：MPLS-in-GRE [MPLS-IP]）です。MPLSを使用すると、このラベルはP-Multicastツリーを識別するラベルのすぐ下に表示されます。MPLS-in-GREを使用すると、このラベルは、GREヘッダーが剥がれたときに表示されるトップMPLSラベルになります。
When IP encapsulation is used for the P-multicast tree, whatever information that particular encapsulation format uses for identifying a particular tunnel is used to determine the label space in which the MPLS label is looked up.
P-MulticastツリーにIPカプセル化が使用される場合、特定のトンネルを識別するために特定のカプセル化形式が使用する情報は、MPLSラベルが検索されるラベル空間を決定するために使用されます。
If the P-multicast tree uses MPLS encapsulation, the P-multicast tree is itself identified by an MPLS label. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree. Once the label representing the tree is popped off the MPLS label stack, the next label is the demultiplexing information that allows the proper MVPN to be determined.
P-MulticastツリーがMPLSカプセル化を使用している場合、P-Multicastツリー自体がMPLSラベルによって識別されます。出口PEは、その木の暗黙のヌルまたは明示的なヌルを宣伝してはなりません。ツリーを表すラベルがMPLSラベルスタックからポップされると、次のラベルは、適切なMVPNを決定できるようにする非複数の表示情報です。
This specification requires that, to support this sort of aggregation, there be at least one upstream-assigned label per MVPN. It does not require that there be only one. For example, an ingress PE could assign a unique label to each (C-S,C-G). (This could be done using the same technique that is used to assign a particular (C-S,C-G) to an S-PMSI, see Section 7.4.)
この仕様では、この種の集約をサポートするには、MVPNごとに少なくとも1つのアップストリーム割り当てラベルがあることが必要です。1つしかないことは必要ありません。たとえば、Ingress PEはそれぞれ（C-S、C-G）に一意のラベルを割り当てることができます。（これは、特定の（C-S、C-G）をS-PMSIに割り当てるために使用されるのと同じ手法を使用して実行できます。セクション7.4を参照してください。）
When an egress PE receives a C-multicast data packet over a P-multicast tree, it needs to forward the packet to the CEs that have receivers in the packet's C-multicast group. In order to do this, the egress PE needs to determine the P-tunnel on which the packet was received. The PE can then determine the MVPN that the packet belongs to and, if needed, do any further lookups that are needed to forward the packet.
出力PEがP-Multicastツリー上でC-Multicastデータパケットを受信する場合、パケットのC-MulticastグループにレシーバーがあるCESにパケットを転送する必要があります。これを行うには、出力PEはパケットが受信されたPトンネルを決定する必要があります。その後、PEはパケットが属するMVPNを決定し、必要に応じてパケットを転送するために必要なルックアップを行うことができます。
While it is believed that the architecture specified in this document places no limitations on the protocols used for setting up and maintaining P-tunnels, the only protocols that have been explicitly considered are PIM-SM (both the SSM and ASM service models are
このドキュメントで指定されているアーキテクチャは、Pタンネルのセットアップと維持に使用されるプロトコルに制限がないと考えられていますが、明示的に考慮されたプロトコルはPIM-SMです（SSMとASMサービスモデルの両方が
considered, as are bidirectional trees), RSVP-TE, mLDP, and BGP. (BGP's role in the setup and maintenance of P-tunnels is to "stitch" together the intra-AS segments of a segmented inter-AS P-tunnel.)
双方向の木と同様に考慮）、RSVP-TE、MLDP、およびBGP。（PタンネルのセットアップとメンテナンスにおけるBGPの役割は、セグメント化されたP-Tunnelのセグメントとしてのセグメントとしての「ステッチ」することです。）
If an I-PMSI is to be instantiated as one or more non-segmented P-tunnels, where the P-tunnels are RSVP-TE P2MP LSPs, then only the PEs that are at the head ends of those LSPs will ever include the PMSI Tunnel attribute in their Intra-AS I-PMSI A-D routes. (These will be the PEs in the "Sender Sites set".)
I-PMSIが1つまたは複数の非セグメント化されたPトゥンネルとしてインスタンス化される場合、P-TunnelsはRSVP-TE P2MP LSPである場合、それらのLSPの頭端にあるPEのみがPMSIを含みます。I-PMSI A-Dルートとしてのトンネル属性。（これらは「Senderサイトセット」のPESになります。）
If an I-PMSI is to be instantiated as one or more segmented P-tunnels, where some of the intra-AS segments of these tunnels are RSVP-TE P2MP LSPs, then only a PE or ASBR that is at the head end of one of these LSPs will ever include the PMSI Tunnel attribute in its Inter-AS I-PMSI A-D route.
I-PMSIが1つ以上のセグメント化されたPタンネルとしてインスタンス化される場合、これらのトンネルの一部のセグメントの一部がRSVP-TE P2MP LSPである場合、1つの頭端にあるPEまたはASBRのみこれらのLSPのうち、PMSIトンネル属性がINTER-AS I-PMSI A-Dルートに含まれます。
Other PEs send Intra-AS I-PMSI A-D routes without PMSI Tunnel attributes. (These will be the PEs that are in the "Receiver Sites set" but not in the "Sender Sites set".) As each "Sender Site" PE receives an Intra-AS I-PMSI A-D route from a PE in the Receiver Sites set, it adds the PE originating that Intra-AS I-PMSI A-D route to the set of receiving PEs for the P2MP LSP. The PE at the head end MUST then use RSVP-TE [RSVP-P2MP] signaling to add the receiver PEs to the P-tunnel.
他のPEは、PMSIトンネル属性なしでIPMSI AS I-PMSI A-Dルートを送信します。（これらは「受信機サイトセット」にあるが、「送信者サイトセット」にはないPESになります。）各「送信者サイト」は、受信者サイトのPEからI-PMSI A-DルートとしてINTRA-AS IPMSI A-Dルートを受け取ります。セットは、P2MP LSPの受信PESのセットにI-PMSI A-Dルートを発信するPEを追加します。ヘッドエンドのPEは、RSVP-TE [RSVP-P2MP]シグナル伝達を使用して、受信機PEをPトンネルに追加する必要があります。
When RSVP-TE P2MP LSPs are used to instantiate S-PMSIs, and a particular C-flow is to be bound to the LSP, it is necessary to use explicit tracking so that the head end of the LSP knows which PEs need to receive data from the specified C-flow. If the binding is done using S-PMSI A-D routes (see Section 7.4.1), the "Leaf Information Required" bit MUST be set in the PMSI Tunnel attribute.
RSVP-TE P2MP LSPを使用してS-PMSISをインスタンス化する場合、特定のCフローをLSPにバインドする場合、LSPのヘッドエンドがデータを受信する必要があることを知っているように、明示的な追跡を使用する必要があります指定されたCフローから。バインディングがS-PMSI A-Dルートを使用して行われた場合（セクション7.4.1を参照）、PMSIトンネル属性に「必要な葉情報」ビットを設定する必要があります。
RSVP-TE P2MP LSPs can optionally support aggregation of multiple MVPNs.
RSVP-TE P2MP LSPは、オプションで複数のMVPNの集約をサポートできます。
If an RSVP-TE P2MP LSP Tunnel is used for only a single MVPN, the mapping between the LSP and the MVPN can either be configured or be deduced from the procedures used to announce the LSP (e.g., from the RTs in the A-D route that announced the LSP). If the LSP is used for multiple MVPNs, the set of MVPNs using it (and the corresponding MPLS labels) is inferred from the PMSI Tunnel attributes that specify the LSP.
RSVP-TE P2MP LSPトンネルが単一のMVPNのみに使用されている場合、LSPとMVPNの間のマッピングを構成するか、LSPを発表するために使用される手順から推定できます（例えば、A-DルートのRTSからLSPを発表）。LSPが複数のMVPNに使用される場合、それを使用するMVPNのセット（および対応するMPLSラベル）は、LSPを指定するPMSIトンネル属性から推測されます。
If an RSVP-TE P2MP LSP is being used to carry a set of C-flows traveling along a bidirectional C-tree, using the procedures of Section 11.2, the head end MUST include the PE Distinguisher Labels
RSVP-TE P2MP LSPを使用して、セクション11.2の手順を使用して、双方向Cフローのセットを運ぶために使用されている場合、ヘッドエンドにはPE distimuisherラベルを含める必要があります。
attribute in its Intra-AS I-PMSI A-D route or S-PMSI A-D route, and it MUST provide an upstream-assigned label for each PE that it has selected as the Upstream PE for the C-tree's RPA (Rendezvous Point Address). See Section 11.2 for details.
INTRA-AS I-PMSI A-DルートまたはS-PMSI A-Dルートの属性であり、C-TreeのRPA（Rendezvous Pointアドレス）の上流PEとして選択した各PEに対して上流で割り当てられたラベルを提供する必要があります。詳細については、セクション11.2を参照してください。
A PMSI Tunnel attribute specifying an RSVP-TE P2MP LSP contains the following information:
RSVP-TE P2MP LSPを指定するPMSIトンネル属性には、次の情報が含まれています。
- The type of the tunnel is set to RSVP-TE P2MP Tunnel
- トンネルのタイプはRSVP-TE P2MPトンネルに設定されています
- The RSVP-TE P2MP Tunnel's SESSION Object.
- RSVP-TE P2MPトンネルのセッションオブジェクト。
- Optionally, the RSVP-TE P2MP LSP's SENDER_TEMPLATE Object. This object is included when it is desired to identify a particular P2MP TE LSP.
- オプションで、RSVP-TE P2MP LSPのsender_templateオブジェクト。このオブジェクトは、特定のP2MP TE LSPを識別することが望ましい場合に含まれています。
Demultiplexing the C-multicast data packets at the egress PE follows procedures described in Section 6.3.3. As specified in Section 6.3.3, an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for an RSVP-TE P2MP LSP that is carrying traffic for one or more MVPNs.
出口PEでのCマルチキャストデータパケットの再屈電圧延長は、セクション6.3.3で説明されている手順に従います。セクション6.3.3で指定されているように、出口PEは、1つ以上のMVPNのトラフィックを運ぶRSVP-TE P2MP LSPの暗黙のヌルまたは明示的なヌルを宣伝してはなりません。
If (and only if) a particular RSVP-TE P2MP LSP is possibly carrying data from multiple MVPNs, the following special procedures apply:
特定のRSVP-TE P2MP LSPが複数のMVPNからデータを運ぶ可能性がある場合（および場合にのみ）、次の特別な手順が適用されます。
- A packet in a particular MVPN, when transmitted into the LSP, must carry the MPLS label specified in the PMSI Tunnel attribute that announced that LSP as a P-tunnel for that for that MVPN.
- 特定のMVPNのパケットは、LSPに送信された場合、そのMVPNのPトンネルとしてLSPを発表したPMSIトンネル属性で指定されたMPLSラベルを運ぶ必要があります。
- Demultiplexing the C-multicast data packets at the egress PE is done by means of the MPLS label that rises to the top of the stack after the label corresponding to the P2MP LSP is popped off.
- P2MP LSPに対応するラベルが飛び出した後、Stackの上部に上昇するMPLSラベルによって、出口PEのCマルチキャストデータパケットの再屈することは行われます。
It is possible that at the time a PE learns, via an A-D route with a PMSI Tunnel attribute, that it needs to receive traffic on a particular RSVP-TE P2MP LSP, the signaling to set up the LSP will not have been completed. In this case, the PE needs to wait for the RSVP-TE signaling to take place before it can modify its forwarding tables as directed by the A-D route.
PEがPMSIトンネル属性を備えたA-Dルートを介して、特定のRSVP-TE P2MP LSPのトラフィックを受信する必要があることを学習している可能性があります。LSPをセットアップするシグナリングは完了していません。この場合、PEは、A-Dルートの指示に従って転送テーブルを変更する前に、RSVP-TEシグナル伝達が行われるのを待つ必要があります。
It is also possible that the signaling to set up an RSVP-TE P2MP LSP will be completed before a given PE learns, via a PMSI Tunnel attribute, of the use to which that LSP will be put. The PE MUST discard any traffic received on that LSP until that time.
また、特定のPEがPMSIトンネル属性を介して、そのLSPが配置される使用を学習する前に、RSVP-TE P2MP LSPを設定するシグナリングが完了する可能性もあります。PEは、その時までそのLSPで受け取ったトラフィックを廃棄する必要があります。
In order for the egress PE to be able to discard such traffic, it needs to know that the LSP is associated with an MVPN and that the A-D route that binds the LSP to an MVPN or to a particular a C-flow has not yet been received. This is provided by extending [RSVP-P2MP] with [RSVP-OOB].
出力PEがそのようなトラフィックを破棄できるようにするためには、LSPがMVPNに関連付けられていること、およびLSPをMVPNまたは特定のA Cフローに結合するA-Dルートがまだされていないことを知る必要があります。受け取った。これは、[RSVP-P2MP]を[RSVP-OOB]で拡張することにより提供されます。
When the P-tunnels are PIM trees, the PMSI Tunnel attribute contains enough information to allow each other PE in the same MVPN to use P-PIM signaling to join the P-tunnel.
PトゥンネルがPIMツリーの場合、PMSIトンネル属性には、同じMVPN内のPEがP-PIMシグナルを使用してPトンネルに参加できるようにするのに十分な情報が含まれています。
If an I-PMSI is to be instantiated as one or more PIM trees, then the PE that is at the root of a given PIM tree sends an Intra-AS I-PMSI A-D route containing a PMSI Tunnel attribute that contains all the information needed for other PEs to join the tree.
I-PMSIが1つ以上のPIMツリーとしてインスタンス化される場合、特定のPIMツリーのルートにあるPEは、必要なすべての情報を含むPMSIトンネル属性を含むI-PMSI A-DルートとしてのINTRA-AS AS IPMSI AS AS AS AS AS AS AS AS ASを送信します。他のPEがツリーに参加するために。
If PIM trees are to be used to instantiate an MI-PMSI, each PE in the MVPN must send an Intra-AS I-PMSI A-D route containing such a PMSI Tunnel attribute.
PIMツリーを使用してMi-PMSIをインスタンス化する場合、MVPN内の各PEは、そのようなPMSIトンネル属性を含むI-PMSI A-DルートとしてIntra-As-As-As As Asを送信する必要があります。
If a PMSI is to be instantiated via a shared tree, the PMSI Tunnel attribute identifies the P-group address. The RP or RPA corresponding to the P-group address is not specified. It must, of course, be known to all the PEs. It is presupposed that the PEs use one of the methods for automatically learning the RP-to-group correspondences (e.g., Bootstrap Router Protocol [BSR]), or else that the correspondence is configured.
PMSIが共有ツリーを介してインスタンス化される場合、PMSIトンネル属性はPグループアドレスを識別します。Pグループアドレスに対応するRPまたはRPAは指定されていません。もちろん、それはすべてのPEに知られている必要があります。PESは、RPからグループへの対応（ブートストラップルータープロトコル[BSR]など）を自動的に学習するための方法の1つを使用していること、または対応が構成されていることを前提としています。
If a PMSI is to be instantiated via a source-specific tree, the PMSI Tunnel attribute identifies the PE router that is the root of the tree, as well as a P-group address. The PMSI Tunnel attribute always specifies whether the PIM tree is to be a unidirectional shared tree, a bidirectional shared tree, or a source-specific tree.
PMSIがソース固有のツリーを介してインスタンス化される場合、PMSIトンネル属性は、ツリーのルートであるPEルーターとPグループアドレスを識別します。PMSIトンネル属性は、PIMツリーが単方向の共有ツリー、双方向の共有ツリー、またはソース固有のツリーであるかどうかを常に指定します。
If PIM trees are being used to instantiate S-PMSIs, the above procedures assume that each PE router has a set of group P-addresses that it can use for setting up the PIM-trees. Each PE must be configured with this set of P-addresses. If the P-tunnels are source-specific trees, then the PEs may be configured with overlapping sets of group P-addresses. If the trees are not source-specific, then each PE must be configured with a unique set of group P-addresses (i.e., having no overlap with the set configured at any other PE router). The management of this set of addresses is thus greatly simplified when source-specific trees are used, so the use of source-specific trees is strongly recommended whenever unidirectional trees are desired.
PIMツリーがS-PMSISをインスタンス化するために使用されている場合、上記の手順では、各PEルーターにはPIMツリーのセットアップに使用できる一連のグループPアドレスがあると想定しています。各PEは、このPアドレスのセットで構成する必要があります。Pタンネルがソース固有のツリーである場合、PESは、グループPアドレスの重複セットで構成される場合があります。ツリーがソース固有でない場合、各PEは、グループPアドレスの一意のセットで構成する必要があります（つまり、他のPEルーターで構成されたセットとオーバーラップすることはありません）。したがって、ソース固有のツリーを使用すると、このアドレスのセットの管理は非常に簡素化されるため、単方向の木が必要になると、ソース固有の木の使用が強く推奨されます。
Specification of the full set of procedures for using bidirectional PIM trees to instantiate S-PMSIs is outside the scope of this document.
双方向PIMツリーを使用してS-PMSISをインスタンス化するための完全な一連の手順の仕様は、このドキュメントの範囲外です。
Details for constructing the PMSI Tunnel attribute identifying a PIM tree can be found in [MVPN-BGP].
PMSIトンネル属性を構築するための詳細PIMツリーを識別することは、[MVPN-BGP]に記載されています。
When the P-tunnels are mLDP P2MP trees, each Intra-AS I-PMSI A-D route has a PMSI Tunnel attribute containing enough information to allow each other PE in the same MVPN to use mLDP signaling to join the P-tunnel. The tunnel identifier consists of a P2MP Forwarding Equivalence Class (FEC) Element [mLDP].
PトゥンネルがMLDP P2MPツリーの場合、各I-PMSI A-Dルートとしての各Intra-Intra-as Asは、同じMVPN内のPEがMLDPシグナルを使用してPトンネルに参加できるように十分な情報を含むPMSIトンネル属性を持っています。トンネル識別子は、P2MP転送等価クラス（FEC）要素[MLDP]で構成されています。
An mLDP P2MP LSP may be used to carry the traffic of multiple VPNs, if the PMSI Tunnel attribute specifying it contains a non-zero MPLS label.
MLDP P2MP LSPを使用して、PMSIトンネル属性に非ゼロMPLSラベルが含まれている場合、複数のVPNのトラフィックを運ぶことができます。
If an mLDP P2MP LSP is being used to carry the set of flows traveling along a particular bidirectional C-tree, using the procedures of Section 11.2, the root of the LSP MUST include the PE Distinguisher Labels attribute in its Intra-AS I-PMSI A-D route or S-PMSI A-D route, and it MUST provide an upstream-assigned label for the PE that it has selected to be the Upstream PE for the C-tree's RPA. See Section 11.2 for details.
MLDP P2MP LSPが、セクション11.2の手順を使用して、特定の双方向Cツリーに沿って移動するフローのセットを運ぶために使用されている場合、LSPのルートには、I-PMSI内にPE distiutisuiSerラベル属性を含める必要があります。A-DルートまたはS-PMSI A-Dルートであり、C-TreeのRPAのアップストリームPEに選択されたPEのアップストリーム割り当てラベルを提供する必要があります。詳細については、セクション11.2を参照してください。
The specification of the procedures for assigning C-flows to mLDP MP2MP LSPs that serve as P-tunnels is outside the scope of this document.
Pトゥンネルとして機能するMLDP MP2MP LSPにC-Flowを割り当てる手順の仕様は、このドキュメントの範囲外です。
As described in Section 3, a PMSI can be instantiated using Unicast Tunnels between the PEs that are participating in the MVPN. In this mechanism, the ingress PE replicates a C-multicast data packet belonging to a particular MVPN and sends a copy to all or a subset of the PEs that belong to the MVPN. A copy of the packet is tunneled to a remote PE over a Unicast Tunnel to the remote PE. IP/GRE Tunnels or MPLS LSPs are examples of unicast tunnels that may be used. The same Unicast Tunnel can be used to transport packets belonging to different MVPNs
セクション3で説明されているように、MVPNに参加しているPES間のユニキャストトンネルを使用してPMSIをインスタンス化できます。このメカニズムでは、Ingress PEは特定のMVPNに属するC-Multicastデータパケットを複製し、MVPNに属するPESのすべてまたはサブセットにコピーを送信します。パケットのコピーは、ユニキャストトンネルを介してリモートPEへのリモートPEにトンネルされています。IP/GREトンネルまたはMPLS LSPは、使用できるユニキャストトンネルの例です。同じユニキャストトンネルを使用して、異なるMVPNに属するパケットを輸送できます
In order for a PE to use Unicast P-tunnels to send a C-multicast data packet for a particular MVPN to a set of remote PEs, the remote PEs must be able to correctly decapsulate such packets and to assign each
PEがユニキャストPタンネルを使用して特定のMVPNのCマルチキャストデータパケットをリモートPEのセットに送信するためには、リモートPEがそのようなパケットを正しく斬首し、それぞれを割り当てることができなければなりません
one to the proper MVPN. This requires that the encapsulation used for sending packets through the P-tunnel have demultiplexing information that the receiver can associate with a particular MVPN.
適切なMVPNの1つ。これには、Pトンネルを介してパケットを送信するために使用されるカプセル化には、受信機が特定のMVPNに関連付けることができる逆転与え情報が必要です。
If ingress replication is being used to instantiate the PMSIs for an MVPN, the PEs announce this as part of the BGP-based MVPN membership auto-discovery process, described in Section 4. The PMSI Tunnel attribute specifies ingress replication; it also specifies a downstream-assigned MPLS label. This label will be used to identify that a particular packet belongs to the MVPN that the Intra-AS I-PMSI A-D route belongs to (as inferred from its RTs). If PE1 specifies a particular label value for a particular MVPN, then any other PE sending PE1 a packet for that MVPN through a unicast P-tunnel must put that label on the packet's label stack. PE1 then treats that label as the demultiplexor value identifying the MVPN in question.
MVPNのPMSIをインスタンス化するためにイングレス複製が使用されている場合、PESは、セクション4で説明されているBGPベースのMVPNメンバーシップオートディスコービリプロセスの一部としてこれを発表します。また、下流に割り当てられたMPLSラベルも指定します。このラベルは、特定のパケットがI-PMSI A-Dルートが（RTSから推測される）に属するMVPNに属していることを識別するために使用されます。PE1が特定のMVPNの特定のラベル値を指定する場合、ユニキャストPトンネルを介してそのMVPNのパケットをPE1に送信する他のPEは、そのラベルをパケットのラベルスタックに配置する必要があります。次に、PE1は、そのラベルを、問題のMVPNを識別するDemultiplexor値として扱います。
Ingress replication may be used to instantiate any kind of PMSI. When ingress replication is done, it is RECOMMENDED, except in the one particular case mentioned in the next paragraph, that explicit tracking be done and that the data packets of a particular C-flow only get sent to those PEs that need to see the packets of that C-flow. There is never any need to use the procedures of Section 7.4 for binding particular C-flows to particular P-tunnels.
侵入レプリケーションは、あらゆる種類のPMSIをインスタンス化するために使用できます。イングレスレプリケーションが行われる場合、次の段落で言及されている特定のケースを除いて、明示的な追跡が行われ、特定のC-flowのデータパケットがパケットを表示する必要があるPESにのみ送信されることを除いて、推奨されます。そのc-flowの。特定のP-tunnelに特定のCフローを結合するために、セクション7.4の手順を使用する必要はありません。
The particular case in which there is no need for explicit tracking is the case where ingress replication is being used to create a one-hop ASBR-ASBR inter-AS segment of an segmented inter-AS P-tunnel.
明示的な追跡の必要がない特定のケースは、セグメント化されたPトンネルのセグメント化されたセグメントとしての1ホップASBR-ASBR間のセグメントを作成するために、イングレス複製が使用されている場合です。
Section 9.1 specifies three different methods that can be used to prevent duplication of multicast data packets. Any given deployment must use at least one of those methods. Note that the method described in Section 9.1.1 ("Discarding Packets from Wrong PE") presupposes that the egress PE of a P-tunnel can, upon receiving a packet from the P-tunnel, determine the identity of the PE that transmitted the packet into the P-tunnel. SPs that use ingress replication to instantiate their PMSIs are cautioned against this use for this purpose of unicast P-tunnel technologies that do not allow the egress PE to identify the ingress PE (e.g., MP2P LSPs for which penultimate-hop-popping is done). Deployment of ingress replication with such P-tunnel technology MUST NOT be done unless it is known that the deployment relies entirely on the procedures of Sections 9.1.2 or 9.1.3 for duplicate prevention.
セクション9.1は、マルチキャストデータパケットの重複を防ぐために使用できる3つの異なる方法を指定します。特定の展開は、これらのメソッドの少なくとも1つを使用する必要があります。セクション9.1.1（「間違ったPEからのパケットの廃棄」）で説明されている方法は、Pトンネルの出力PEがPトンネルからパケットを受け取ったときに、送信されたPEのアイデンティティを決定することができることを前提としていることに注意してください。Pトンネルにパケット。Ingressレプリケーションを使用してPMSIをインスタンス化するSPSは、出口PEがイングレスPEを識別できないユニキャストPトンネルテクノロジーのこの目的のために、この使用に対して警告されています（例えば、ペナルテーションホップポッピングが行われるMP2P LSP）。このようなPトンネルテクノロジーによるイングレスレプリケーションの展開は、展開が重複予防のためにセクション9.1.2または9.1.3の手順に完全に依存していることがわかっていない限り、実行してはならない。
As discussed previously, Intra-AS I-PMSI A-D routes may (or may not) have PMSI Tunnel attributes, identifying P-tunnels that can be used as the default P-tunnels for carrying C-multicast traffic, i.e., for carrying C-multicast traffic that has not been specifically bound to another P-tunnel.
前述のように、INTRA-AS I-PMSI A-Dルートは、PMSIトンネル属性を持つ可能性があります（またはそうでない場合があります）。特に別のPトンネルに拘束されていないマルチキャストトラフィック。
If none of the Intra-AS I-PMSI A-D routes originated by a particular PE for a particular MVPN carry PMSI Tunnel attributes at all (or if the only PMSI Tunnel attributes they carry have type "No tunnel information present"), then there are no default P-tunnels for that PE to use when transmitting C-multicast traffic in that MVPN to other PEs. In that case, all such C-flows must be assigned to specific P-tunnels using one of the mechanisms specified in Section 7.4. That is, all such C-flows are carried on P-tunnels that instantiate S-PMSIs.
特定のMVPNキャリーPMSIトンネル属性の特定のPEから発信されたINTRA-AS I-PMSI A-Dルートのいずれもまったくない場合（または、それらが携帯する唯一のPMSIトンネル属性に「トンネル情報が存在しない」というタイプがある場合、そのMVPN内のC-Multicastトラフィックを他のPEに送信するときに使用するPEのデフォルトのPターンはありません。その場合、そのようなすべてのC-flowは、セクション7.4で指定されたメカニズムのいずれかを使用して、特定のPタンネルに割り当てる必要があります。つまり、そのようなC-Flowはすべて、S-PMSIをインスタンス化するPタンネルで運ばれます。
There are other cases where it may be either necessary or desirable to use the mechanisms of Section 7.4 to identify specific C-flows and bind them to or unbind them from specific P-tunnels. Some possible cases are as follows:
セクション7.4のメカニズムを使用して特定のcフローを識別し、特定のPタンネルからそれらにバインドするか、それらをバインドすることが必要または望ましい場合がある他のケースがあります。いくつかの可能なケースは次のとおりです。
- The policy for a particular MVPN is to send all C-data on S-PMSIs, even if the Intra-AS I-PMSI A-D routes carry PMSI Tunnel attributes. (This is another case where all C-data is carried on S-PMSIs; presumably, the I-PMSIs are used for control information.)
- 特定のMVPNのポリシーは、INTRA-AS I-PMSI A-DルートがPMSIトンネル属性を運ぶ場合でも、すべてのC-DATAをS-PMSISに送信することです。（これは、すべてのC-DATAがS-PMSISで運ばれる別のケースです。おそらく、I-PMSISは制御情報に使用されます。）
- It is desired to optimize the routing of the particular C-flow, which may already be traveling on an I-PMSI, by sending it instead on an S-PMSI.
- 代わりにS-PMSIで送信することにより、すでにI-PMSIで移動している可能性のある特定のC-Flowのルーティングを最適化することが望まれます。
- If a particular C-flow is traveling on an S-PMSI, it may be considered desirable to move it to an I-PMSI (i.e., optimization of the routing for that flow may no longer be considered desirable).
- 特定のCフローがS-PMSIで移動している場合、I-PMSIに移動することが望ましいと見なされる場合があります（つまり、そのフローのルーティングの最適化は、もはや望ましくないと見なされる可能性があります）。
- It is desired to change the encapsulation used to carry the C-flow, e.g., because one now wants to aggregate it on a P-tunnel with flows from other MVPNs.
- たとえば、C-flowを運ぶために使用されるカプセル化を変更することが望まれます。これは、他のMVPNからのフローを備えたPトンネルに集約したいためです。
Note that if Full PIM Peering over an MI-PMSI (Section 5.2) is being used, then from the perspective of the PIM state machine, the "interface" connecting the PEs to each other is the MI-PMSI, even if some or all of the C-flows are being sent on S-PMSIs. That is, from
Mi-PMSI（セクション5.2）を介して完全なPIMピアリングが使用されている場合、PIM Stateマシンの観点から、PEを互いに接続する「インターフェイス」はMi-PMSIです。C-flowsはS-PMSISで送信されています。それは、からです
the perspective of the C-PIM state machine, when a C-flow is being sent or received on an S-PMSI, the output or input interface (respectively) is considered to be the MI-PMSI.
C-PIM状態マシンの視点は、c-flowがS-PMSIで送信または受信されている場合、出力または入力インターフェイス（それぞれ）がMI-PMSIと見なされます。
Section 7.1 discusses certain general considerations that apply whenever a specified C-flow is bound to a specified P-tunnel using the mechanisms of Section 7.4. This includes the case where the C-flow is moved from one P-tunnel to another as well as the case where the C-flow is initially bound to an S-PMSI P-tunnel.
セクション7.1では、セクション7.4のメカニズムを使用して、指定されたCフローが指定されたPトンネルに結合している場合はいつでも適用される特定の一般的な考慮事項について説明します。これには、Cフローが1つのPトンネルから別のPターンネルに移動される場合、およびCフローが最初にS-PMSI Pトンネルに結合されている場合が含まれます。
Section 7.2 discusses the specific case of using the mechanisms of Section 7.4 as a way of optimizing multicast routing by switching specific flows from one P-tunnel to another.
セクション7.2では、特定のフローをあるPトンネルから別のPターンネルに切り替えることにより、マルチキャストルーティングを最適化する方法としてセクション7.4のメカニズムを使用する特定のケースについて説明します。
Section 7.3 discusses the case where the mechanisms of Section 7.4 are used to announce the presence of "unsolicited flooded data" and to assign such data to a particular P-tunnel.
セクション7.3では、セクション7.4のメカニズムが「未承諾の洪水データ」の存在を発表し、そのようなデータを特定のPトンネルに割り当てるために使用される場合について説明します。
Section 7.4 specifies the protocols for assigning specific C-flows to specific P-tunnels. These protocols may be used to assign a C-flow to a P-tunnel initially or to switch a flow from one P-tunnel to another.
セクション7.4は、特定のC-Flowを特定のPタンネルに割り当てるためのプロトコルを指定します。これらのプロトコルを使用して、最初にPトンネルにCフローを割り当てるか、1つのPトンネルから別のPターンネルにフローを切り替えることができます。
Procedures for binding to a specified P-tunnel the set of C-flows traveling along a specified C-tree (or for so binding a set of C-flows that share some relevant characteristic), without identifying each flow individually, are outside the scope of this document.
指定されたPトンネルに結合する手順指定されたCツリーに沿って移動するC-Flowsのセット（または、関連する特性を共有するC-Flowsのセットを結合するため）は、各フローを個別に識別せずに範囲外です。このドキュメントの。
The decision to bind a particular C-flow (designated as (C-S,C-G)) to a particular P-tunnel, or to switch a particular C-flow to a particular P-tunnel, is always made by the PE that is to transmit the C-flow onto the P-tunnel.
特定のCフロー（（c-s、c-g）として指定）を特定のPトンネルにバインドするか、特定のCフローを特定のPトンネルに切り替えるという決定は、送信するPEによって常に作成されますPトンネル上のCフロー。
Whenever a PE moves a particular C-flow from one P-tunnel, say P1, to another, say P2, care must be taken to ensure that there is no steady state duplication of traffic. At any given time, the PE transmits the C-flow either on P1 or on P2, but not on both.
PEが特定のCフローを1つのPトンネル（P1など）から別のP2に移動するときはいつでも、トラフィックの定常状態の重複がないことを確認するために注意する必要があります。いつでも、PEはP1またはP2でC-flowを送信しますが、両方ではありません。
When a particular PE, say PE1, decides to bind a particular C-flow to a particular P-tunnel, say P2, the following procedures MUST be applied:
たとえばPE1が特定のCフローを特定のPトンネルに結合することを決定した場合、P2は次の手順を適用する必要があります。
- PE1 must issue the required control plane information to signal that the specified C-flow is now bound to P-tunnel P2 (see Section 7.4).
- PE1は、指定されたCフローがPトンネルP2に結合していることを示すために、必要な制御プレーン情報を発行する必要があります（セクション7.4を参照）。
- If P-tunnel P2 needs to be constructed from the root downwards, PE1 must initiate the signaling to construct P2. This is only required if P2 is an RSVP-TE P2MP LSP.
- p-tunnel P2をルートから下向きに構築する必要がある場合、PE1はP2を構築するためにシグナル伝達を開始する必要があります。これは、P2がRSVP-TE P2MP LSPである場合にのみ必要です。
- If the specified C-flow is currently bound to a different P-tunnel, say P1, then:
- 指定されたCフローが現在別のPトンネルに結合している場合、P1と言います。
* PE1 MUST wait for a "switch-over" delay before sending traffic of the C-flow on P-tunnel P2. It is RECOMMENDED to allow this delay to be configurable.
* PE1は、PトンネルP2にCフローのトラフィックを送信する前に、「スイッチオーバー」遅延を待つ必要があります。この遅延を構成可能にすることをお勧めします。
* Once the "switch-over" delay has elapsed, PE1 MUST send traffic for the C-flow on P2 and MUST NOT send it on P1. In no case is any C-flow packet sent on both P-tunnels.
* 「スイッチオーバー」遅延が経過したら、PE1はP2のCフローのトラフィックを送信する必要があり、P1に送信してはなりません。どちらの場合も、両方のPタンネルに送信されるCフローパケットはありません。
When a C-flow is switched from one P-tunnel to another, the purpose of running a switch-over timer is to minimize packet loss without introducing packet duplication. However, jitter may be introduced due to the difference in transit delays between the old and new P-tunnels.
C-flowが1つのPトンネルから別のPターンネルに切り替えられると、スイッチオーバータイマーを実行する目的は、パケットの複製を導入せずにパケット損失を最小限に抑えることです。ただし、古いPタンネルと新しいPタンネル間の輸送遅延の違いにより、ジッターが導入される場合があります。
For best effect, the switch-over timer should be configured to a value that is "just long enough" (a) to allow all the PEs to learn about the new binding of C-flow to P-tunnel and (b) to allow the PEs to construct the P-tunnel, if it doesn't already exist.
最善の効果を得るには、スイッチオーバータイマーを「十分に長い」（a）c-flowの新しいバインディングについてPESと（b）に学習できるようにするために、「十分に長い」（a）値に構成する必要があります。PESがPESを構築するために、PESはまだ存在していない場合。
If, after such a switch, the "old" P-tunnel P1 is no longer needed, it SHOULD be torn down and the resources supporting it freed. The procedures for "tearing down" a P-tunnel are specific to the P-tunnel technology.
そのような切り替えの後、「古い」PトンネルP1が不要になった場合、それは取り壊され、それをサポートするリソースを解放する必要があります。Pトゥンネルを「引き裂く」ための手順は、Pトンネル技術に固有のものです。
Procedures for binding sets of C-flows traveling along specified C-trees (or sets of C-flows sharing any other characteristic) to a specified P-tunnel (or for moving them from one P-tunnel to another) are outside the scope of this document.
指定されたCフロー（または、他の特性を共有するC-Flowsのセット）に沿って移動するC-Flowの結合セットの手順（または、それらをあるPターンネルから別のPターンネルに移動するため）は、の範囲外ですこのドキュメント。
Suppose that a particular PE, say PE1, learns, via the procedures of Section 7.4, that some other PE, say PE2, has bound a particular C-flow, designated as (C-S,C-G), to a particular P-tunnel, say P2. Then, PE1 must determine whether it needs to receive (C-S,C-G) traffic from PE2.
特定のPE、たとえばPE1がセクション7.4の手順を介して、他のPE、PE2が特定のCフロー（C-S、C-G）として指定された特定のPトンネルに結合していることを学習していると仮定します。P2。次に、PE1がPE2から（C-S、C-G）トラフィックを受信する必要があるかどうかを判断する必要があります。
If BGP is being used to distribute C-multicast routing information from PE to PE, the conditions under which PE1 needs to receive (C-S,C-G) traffic from PE2 are specified in Section 12.3 of [MVPN-BGP].
BGPがC-Multicastルーティング情報をPEからPEに配布するために使用されている場合、PE1がPE2から（C-S、C-G）トラフィックを受信する必要がある条件が[MVPN-BGP]のセクション12.3で指定されています。
If PIM over an MI-PMSI is being used to distribute C-multicast routing from PE to PE, PE1 needs to receive (C-S,C-G) traffic from PE2 if one or more of the following conditions holds:
Mi-PMSIを介したPIMがPEからPEへのc-Multicastルーティングを配布するために使用されている場合、PE1がPE2から（C-S、C-G）トラフィックを受信する必要があります。
- PE1 has (C-S,C-G) state such that PE2 is PE1's Upstream PE for (C-S,C-G), and PE1 has downstream neighbors ("non-null olist") for the (C-S,C-G) state.
- PE1は（C-S、C-G）状態を持っているため、PE2は（C-S、C-G）のPE1の上流PEであり、PE1は（C-S、C-G）状態に対して下流の隣接（「非nullオリスト」）を持っています。
- PE1 has (C-*,C-G) state with an Upstream PE (not necessarily PE2) and with downstream neighbors ( "non-null olist"), but PE1 does not have (C-S,C-G) state.
- PE1には（C-*、C-G）状態が上流のPE（必ずしもPE2）および下流の隣接（「非nullオリスト」）を備えていますが、PE1には（c-s、c-g）状態がありません。
- Native PIM methods are being used to prevent steady-state packet duplication, and PE1 has either (C-*,C-G) or (C-S,C-G) state such that the MI-PMSI is one of the downstream interfaces. Note that this includes the case where PE1 is itself sending (C-S,C-G) traffic on an S-PMSI. (In this case, PE1 needs to receive the (C-S,C-G) traffic from PE2 in order to allow the PIM Assert mechanism to function properly.)
- ネイティブPIMメソッドは、定常状態のパケットの複製を防ぐために使用されており、PE1には（C-*、C-G）または（C-S、C-G）状態があり、Mi-PMSIが下流のインターフェイスの1つになります。これには、PE1自体がS-PMSIで（C-S、C-G）トラフィックを送信している場合に注意してください。（この場合、PE1はPE2から（C-S、C-G）トラフィックを受け取る必要があります。
Irrespective of whether BGP or PIM is being used to distribute C-multicast routing information, once PE1 determines that it needs to receive (C-S,C-G) traffic from PE2, the following procedures MUST be applied:
BGPまたはPIMがC-Multicastルーティング情報の配布に使用されているかどうかに関係なく、PE1がPE2から（C-S、C-G）トラフィックを受信する必要があると判断したら、次の手順を適用する必要があります。
- PE1 MUST take all necessary steps to be able to receive the (C-S,C-G) traffic on P2.
- PE1は、P2で（C-S、C-G）トラフィックを受信できるようにするために必要なすべての措置を講じる必要があります。
* If P2 is a PIM tunnel or an mLDP LSP, PE1 will need to use PIM or mLDP (respectively) to join P2 (unless it is already joined to P2).
* P2がPIMトンネルまたはMLDP LSPである場合、PE1はPIMまたはMLDP（それぞれ）を使用してP2に参加する必要があります（P2に既に結合されていない限り）。
* PE1 may need to modify the forwarding state for (C-S,C-G) to indicate that (C-S,C-G) traffic is to be accepted on P2. If P2 is an Aggregate Tree, this also implies setting up the demultiplexing forwarding entries based on the inner label as described in Section 6.3.3
* （C-S、C-G）のトラフィックがP2で受け入れられることを示すために、PE1は（C-S、C-G）の転送状態を変更する必要がある場合があります。P2が集計ツリーである場合、これはセクション6.3.3で説明されている内部ラベルに基づいて、非拡張転送エントリのセットアップを意味することも意味します。
- If PE1 was previously receiving the (C-S,C-G) C-flow on another P-tunnel, say P1, then:
- PE1が以前に別のPトンネルで（C-S、C-G）C-Flowを受け取っていた場合、P1と言います。
* PE1 MAY run a switch-over timer, and until it expires, SHOULD accept traffic for the given C-flow on both P1 and P2;
* PE1はスイッチオーバータイマーを実行する場合があり、有効期限が切れるまで、P1とP2の両方で指定されたCフローのトラフィックを受け入れる必要があります。
* If, after such a switch, the "old" P-tunnel P1 is no longer needed, it SHOULD be torn down and the resources supporting it freed. The procedures for "tearing down" a P-tunnel are specific to the P-tunnel technology.
* そのような切り替えの後、「古い」PトンネルP1が不要になった場合、それは取り壊され、それをサポートするリソースを解放する必要があります。Pトゥンネルを「引き裂く」ための手順は、Pトンネル技術に固有のものです。
- If PE1 later determines that it no longer needs to receive any of the C-multicast data that is being sent on a particular P-tunnel, it may initiate signaling (specific to the P-tunnel technology) to remove itself from that tunnel.
- 後にPE1が特定のPトンネルで送信されているCマルチキャストデータを受信する必要がなくなったと判断した場合、そのトンネルからそれ自体を除去するためにシグナリング（Pトンネル技術に固有）を開始する可能性があります。
Whenever a particular multicast stream is being sent on an I-PMSI, it is likely that the data of that stream is being sent to PEs that do not require it. If a particular stream has a significant amount of traffic, it may be beneficial to move it to an S-PMSI that includes only those PEs that are transmitters and/or receivers (or at least includes fewer PEs that are neither).
特定のマルチキャストストリームがI-PMSIで送信されているときはいつでも、そのストリームのデータがそれを必要としないPESに送信されている可能性があります。特定のストリームにかなりの量のトラフィックがある場合、送信機および/または受信機である（または少なくともどちらのものも少なくとも少なく含まれているPESを含む）を含むS-PMSIに移動することが有益かもしれません。
If explicit tracking is being done, S-PMSI creation can also be triggered on other criteria. For instance, there could be a "pseudo-wasted bandwidth" criterion: switching to an S-PMSI would be done if the bandwidth multiplied by the number of uninterested PEs (PE that are receiving the stream but have no receivers) is above a specified threshold. The motivation is that (a) the total bandwidth wasted by many sparsely subscribed low-bandwidth groups may be large and (b) there's no point to moving a high-bandwidth group to an S-PMSI if all the PEs have receivers for it.
明示的な追跡が行われている場合、S-PMSI作成は他の基準でもトリガーできます。たとえば、「擬似廃棄された帯域幅」の基準がある可能性があります。帯域幅に無関心なPEの数（ストリームを受信しているがレシーバーがないPE）の数に帯域幅に乗算すると、S-PMSIへの切り替えが行われます。しきい値。動機は、（a）多くのまばらに登録された低帯域幅グループによって無駄にされる総帯域幅が大きく、（b）すべてのPESがそのための受信機を持っている場合、高帯域幅グループをS-PMSIに移動する意味がないことです。
Switching a (C-S,C-G) stream to an S-PMSI may require the root of the S-PMSI to determine the egress PEs that need to receive the (C-S,C-G) traffic. This is true in the following cases:
（C-S、C-G）ストリームをS-PMSIに切り替えるには、（C-S、C-G）トラフィックを受信する必要がある出力PEを決定するためにS-PMSIのルートを必要とする場合があります。これは、次の場合に当てはまります。
- If the P-tunnel is a source-initiated tree, such as an RSVP-TE P2MP Tunnel, the PE needs to know the leaves of the tree before it can instantiate the S-PMSI.
- PトンネルがRSVP-TE P2MPトンネルなどのソース開始ツリーである場合、PEはS-PMSIをインスタンス化する前にツリーの葉を知る必要があります。
- If a PE instantiates multiple S-PMSIs, belonging to different MVPNs, using one P-multicast tree, such a tree is termed an Aggregate Tree with a selective mapping. The setting up of such an Aggregate Tree requires the ingress PE to know all the other PEs that have receivers for multicast groups that are mapped onto the tree.
- PEが1つのp-multicastツリーを使用して異なるMVPNに属する複数のS-PMSISをインスタンス化する場合、そのようなツリーは選択的マッピングを備えた骨材ツリーと呼ばれます。このような骨材のツリーのセットアップには、ツリーにマッピングされたマルチキャストグループ用の受信機を持つ他のすべてのPEを知るために、侵入PEが必要です。
The above two cases require that explicit tracking be done for the (C-S,C-G) stream. The root of the S-PMSI MAY decide to do explicit tracking of this stream only after it has determined to move the stream to an S-PMSI, or it MAY have been doing explicit tracking all along.
上記の2つのケースでは、（C-S、C-G）ストリームに対して明示的な追跡を行う必要があります。S-PMSIのルートは、ストリームをS-PMSIに移動することを決定した後にのみ、このストリームの明示的な追跡を行うことを決定する場合があります。
If the S-PMSI is instantiated by a P-multicast tree, the PE at the root of the tree must signal the leaves of the tree that the (C-S,C-G) stream is now bound to the S-PMSI. Note that the PE could create the identity of the P-multicast tree prior to the actual instantiation of the P-tunnel.
S-PMSIがP-Multicastツリーによってインスタンス化されている場合、ツリーの根のPEは、（C-S、C-G）ストリームがS-PMSIに結合していることをツリーの葉に信号する必要があります。PEは、Pトンネルの実際のインスタンス化の前にP-Multicastツリーのアイデンティティを作成できることに注意してください。
If the S-PMSI is instantiated by a source-initiated P-multicast tree (e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree must establish the source-initiated P-multicast tree to the leaves. This tree MAY have been established before the leaves receive the S-PMSI binding, or it MAY be established after the leaves receive the binding. The leaves MUST NOT switch to the S-PMSI until they receive both the binding and the tree signaling message.
S-PMSIが発生源開始P-Multicastツリー（たとえば、RSVP-TE P2MPトンネルなど）によってインスタンス化されている場合、ツリーの根のPEは、葉にソースが開始したP-Multicastツリーを確立する必要があります。この木は、葉がS-PMSI結合を受ける前に確立された可能性があります。または、葉が結合を受け取った後に確立される場合があります。葉は、バインディングとツリーの信号メッセージの両方を受け取るまで、S-PMSIに切り替えてはなりません。
A PE may receive "unsolicited" data from a CE, where the data is intended to be flooded to the other PEs of the same MVPN and then on to other CEs. By "unsolicited", we mean that the data is to be delivered to all the other PEs of the MVPN, even though those PEs may not have sent any control information indicating that they need to receive that data.
PEは、CEから「未承諾」データを受け取る場合があります。ここでは、データが同じMVPNの他のPEに浸水し、他のCESに浸水することを目的としています。「未承諾」とは、データがMVPNの他のすべてのPEに配信されることを意味します。
For example, if the BSR [BSR] is being used within the MVPN, BSR control messages may be received by a PE from a CE. These need to be forwarded to other PEs, even though no PE ever issues any kind of explicit signal saying that it wants to receive BSR messages.
たとえば、BSR [BSR]がMVPN内で使用されている場合、BSR制御メッセージはCEからPEによって受信される場合があります。これらは、BSRメッセージを受信したいという明示的な信号を発行することはありませんが、他のPEに転送する必要があります。
If a PE receives a BSR message from a CE, and if the CE's MVPN has an MI-PMSI, then the PE can just send BSR messages on the appropriate P-tunnel. Otherwise, the PE MUST announce the binding of a particular C-flow to a particular P-tunnel, using the procedures of Section 7.4. The particular C-flow in this case would be (C-IPaddress_of_PE, ALL-PIM-ROUTERS). The P-tunnel identified by the procedures of Section 7.4 may or may not be one that was previously identified in the PMSI Tunnel attribute of an I-PMSI A-D route. Further procedures for handling BSR may be found in Sections 5.2.1 and 5.3.4.
PEがCEからBSRメッセージを受信し、CEのMVPNにMi-PMSIがある場合、PEは適切なPトンネルでBSRメッセージを送信するだけです。それ以外の場合、PEは、セクション7.4の手順を使用して、特定のPトンネルへの特定のCフローの結合を発表する必要があります。この場合の特定のc-flowは（c-ipaddress_of_pe、all-pim-routers）です。セクション7.4の手順で特定されたPトンネルは、I-PMSI A-DルートのPMSIトンネル属性で以前に識別されたものである場合とそうでない場合があります。BSRを処理するためのさらなる手順は、セクション5.2.1および5.3.4に記載されている場合があります。
Analogous procedures may be used for announcing the presence of other sorts of unsolicited flooded data, e.g., dense mode data or data from proprietary protocols that presume messages can be flooded. However, a full specification of the procedures for traffic other than BSR traffic is outside the scope of this document.
類似の手順は、他の種類の未承諾の浸水データの存在を発表するために使用される場合があります。たとえば、メッセージを浸水させる可能性があると仮定する独自のプロトコルからの密なモードデータまたはデータ。ただし、BSRトラフィック以外のトラフィックの手順の完全な指定は、このドキュメントの範囲外です。
We describe two protocols for binding C-flows to P-tunnels.
PタンネルにC-flowを結合するための2つのプロトコルについて説明します。
These protocols can be used for moving C-flows from I-PMSIs to S-PMSIs, as long as the S-PMSI is instantiated by a P-multicast tree. (If the S-PMSI is instantiated by means of ingress replication, the procedures of Section 6.4.5 suffice.)
これらのプロトコルは、S-PMSIがP-Multicastツリーによってインスタンス化されている限り、I-PMSISからS-PMSISにC-Flowを移動するために使用できます。（S-PMSIが侵入レプリケーションによってインスタンス化されている場合、セクション6.4.5の手順で十分です。）
These protocols can also be used for other cases in which it is necessary to bind specific C-flows to specific P-tunnels.
これらのプロトコルは、特定のCフローを特定のPタンネルにバインドする必要がある他のケースにも使用できます。
Not withstanding the name of the mechanism "S-PMSI A-D routes", the mechanism to be specified in this section may be used any time it is necessary to advertise a binding of a C-flow to a particular P-tunnel.
メカニズム「S-PMSI A-Dルート」の名前に耐えられないように、このセクションで指定するメカニズムは、特定のPトンネルへのCフローの結合を宣伝する必要があるときにいつでも使用できます。
The ingress PE informs all the PEs that are on the path to receivers of the (C-S,C-G) of the binding of the P-tunnel to the (C-S,C-G). The BGP announcement is done by sending an update for the MCAST-VPN address family. An S-PMSI A-D route is used, containing the following information:
Ingress PEは、pターンネルの（c-s、c-g）への結合の（c-s、c-g）の受信機への経路にあるすべてのPESに通知します。BGPの発表は、MCAST-VPNアドレスファミリのアップデートを送信することで行われます。次の情報を含むS-PMSI A-Dルートが使用されます。
1. The IP address of the originating PE.
1. 発生PEのIPアドレス。
2. The RD configured locally for the MVPN. This is required to uniquely identify the (C-S,C-G) as the addresses could overlap between different MVPNs. This is the same RD value used in the auto-discovery process.
2. RDは、MVPN用にローカルに構成されています。これは、アドレスが異なるMVPNの間で重複する可能性があるため、（C-S、C-G）を一意に識別するために必要です。これは、自動発見プロセスで使用される同じRD値です。
3. The C-S address.
3. C-Sアドレス。
4. The C-G address.
4. C-Gアドレス。
5. A PE MAY use a single P-tunnel to aggregate two or more S-PMSIs. If the PE already advertised unaggregated S-PMSI A-D routes for these S-PMSIs, then a decision to aggregate them requires the PE to re-advertise these routes. The re-
5. PEは、単一のPトンネルを使用して、2つ以上のS-PMSIを集約する場合があります。PEがこれらのS-PMSISの凝集していないS-PMSI A-Dルートを既に宣伝している場合、それらを集約する決定には、これらのルートを再承認するためにPEが必要です。そこには-
advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised S-PMSI A-D routes for these S-PMSIs, then the aggregation requires the PE to advertise (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-tunnel that aggregates the S-PMSIs.
広告されたルートは、PMSIトンネル属性を除き、元のルートと同じでなければなりません。PEがこれらのS-PMSIのS-PMSI A-Dルートを以前に宣伝していなかった場合、集約はこれらのS-PMSIの広告（新しい）S-PMSI A-Dルートを広告する必要があります。新しく宣伝された/再承認されたルートのPMSIトンネル属性は、S-PMSISを集約するPトンネルのIDを運ぶ必要があります。
If all these aggregated S-PMSIs belong to the same MVPN, and this MVPN uses PIM as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned label [MPLS-UPSTREAM-LABEL]. Moreover, in this case, the labels MUST be distinct on a per-MVPN basis, and MAY be distinct on a per-route basis.
これらすべての凝集したS-PMSISが同じMVPNに属し、このMVPNがPIMをC-Multicastルーティングプロトコルとして使用している場合、対応するS-PMSI A-DルートはMPLSアップストリーム割り当てラベル[MPLS-Upstream-Label]を運ぶ場合があります。さらに、この場合、ラベルはMVPNごとに明確でなければならず、ルートごとに異なる場合があります。
If all these aggregated S-PMSIs belong to the MVPN(s) that use mLDP as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MUST carry an MPLS upstream-assigned label [MPLS-UPSTREAM-LABEL], and these labels MUST be distinct on a per-route (per-mLDP-FEC) basis, irrespective of whether the aggregated S-PMSIs belong to the same or different MVPNs.
これらすべての集約されたS-PMSISがMLDPをC-Multicastルーティングプロトコルとして使用するMVPNに属している場合、対応するS-PMSI A-DルートはMPLSアップストリーム割り当てラベル[MPLS-Upstream-Label]、およびこれらのラベルは、集約されたS-PMSIが同じまたは異なるMVPNに属しているかどうかに関係なく、ルートごと（PER-MLDP-FEC）ベースで異なる必要があります。
When a PE distributes this information via BGP, it must include the following:
PEがBGPを介してこの情報を配布する場合、以下を含める必要があります。
1. An identifier for the particular P-tunnel to which the stream is to be bound. This identifier is a structured field that includes the following information:
1. ストリームをバインドする特定のPトンネルの識別子。この識別子は、次の情報を含む構造化されたフィールドです。
* The type of tunnel
* トンネルのタイプ
* An identifier for the tunnel. The form of the identifier will depend upon the tunnel type. The combination of tunnel identifier and tunnel type should contain enough information to enable all the PEs to "join" the tunnel and receive messages from it.
* トンネルの識別子。識別子の形式は、トンネルタイプに依存します。トンネル識別子とトンネルタイプの組み合わせには、すべてのPEがトンネルに「結合」してメッセージを受信できるようにするのに十分な情報を含める必要があります。
2. Route Target Extended Communities attribute. This is used as described in Section 4.
2. ルートターゲット拡張コミュニティ属性。これは、セクション4で説明されているように使用されます。
If the PE wants to enable explicit tracking for the specified flow, it also indicates this in the A-D route it uses to bind the flow to a particular P-tunnel. Then, any PE that receives the A-D route will
PEが指定されたフローの明示的な追跡を有効にしたい場合、これは、フローを特定のPトンネルに結合するために使用するA-Dルートでもこれを示します。次に、A-Dルートを受信するPEは
respond with a "Leaf A-D route" in which it identifies itself as a receiver of the specified flow. The Leaf A-D route will be withdrawn when the PE is no longer a receiver for the flow.
指定されたフローの受信機として識別する「リーフA-Dルート」で応答します。PEが流れの受信機ではなくなった場合、葉のA-Dルートは引き出されます。
If the PE needs to enable explicit tracking for a flow without at the same time binding the flow to a specific P-tunnel, it can do so by sending an S-PMSI A-D route whose NLRI identifies the flow and whose PMSI Tunnel attribute has its tunnel type value set to "no tunnel information present" and its "leaf information required" bit set to 1. This will elicit the Leaf A-D routes. This is useful when the PE needs to know the receivers before selecting a P-tunnel.
PEが同時にフローを特定のPトンネルに結合せずにフローの明示的な追跡を有効にする必要がある場合、NLRIがフローを識別し、PMSIトンネル属性にそのs-PMSI A-Dルートを送信することでそうすることができます。トンネルタイプの値は、「トンネル情報が存在しない」に設定され、その「葉の情報が必要」ビットを1に設定します。これにより、葉のA-Dルートが誘発されます。これは、Pトンネルを選択する前にPEが受信機を知る必要がある場合に役立ちます。
This procedure carries its control messages in UDP and requires that the MVPN have an MI-PMSI that can be used to carry the control messages.
この手順では、UDPでの制御メッセージが届き、MVPNには制御メッセージの運搬に使用できるMi-PMSIが必要です。
In order for a given PE to move a particular C-flow to a particular P-tunnel, an "S-PMSI Join message" is sent periodically on the MI-PMSI. (Notwithstanding the name of the mechanism, the mechanism may be used to bind a flow to any P-tunnel.) The S-PMSI Join message is a UDP-encapsulated message whose destination address is ALL-PIM-ROUTERS (224.0.0.13) and whose destination port is 3232.
特定のPEが特定のCフローを特定のPトンネルに移動するために、「S-PMSI結合メッセージ」がMi-PMSIで定期的に送信されます。（メカニズムの名前にもかかわらず、メカニズムを使用してフローをPトンネルに結合するために使用できます。）S-PMSI結合メッセージは、宛先アドレスがオールピムルーター（224.0.0.13）であるUDPにカプセル化されたメッセージです。宛先ポートは3232です。
The S-PMSI Join message contains the following information:
S-PMSI結合メッセージには、次の情報が含まれています。
- An identifier for the particular multicast stream that is to be bound to the P-tunnel. This can be represented as an (S,G) pair.
- Pトンネルにバインドされる特定のマルチキャストストリームの識別子。これは、（s、g）ペアとして表すことができます。
- An identifier for the particular P-tunnel to which the stream is to be bound. This identifier is a structured field that includes the following information:
- ストリームをバインドする特定のPトンネルの識別子。この識別子は、次の情報を含む構造化されたフィールドです。
* The type of tunnel used to instantiate the S-PMSI.
* S-PMSIをインスタンス化するために使用されるトンネルのタイプ。
* An identifier for the tunnel. The form of the identifier will depend upon the tunnel type. The combination of tunnel identifier and tunnel type should contain enough information to enable all the PEs to "join" the tunnel and receive messages from it.
* トンネルの識別子。識別子の形式は、トンネルタイプに依存します。トンネル識別子とトンネルタイプの組み合わせには、すべてのPEがトンネルに「結合」してメッセージを受信できるようにするのに十分な情報を含める必要があります。
* If (and only if) the identified P-tunnel is aggregating several S-PMSIs, any demultiplexing information needed by the tunnel encapsulation protocol to identify a particular S-PMSI.
* 特定されたPトンネルがいくつかのS-PMSIを集約している場合（および場合にのみ）、トンネルカプセル化プロトコルが特定のS-PMSIを識別するために必要な非複数形成情報。
If the policy for the MVPN is that traffic is sent/received by default over an MI-PMSI, then traffic for a particular C-flow can be switched back to the MI-PMSI simply by ceasing to send S-PMSI Joins for that C-flow.
MVPNのポリシーがMi-PMSIでデフォルトでトラフィックが送信/受信されることである場合、特定のCフローのトラフィックは、単にそのcのS-PMSI結合を送信するために停止するだけでMi-PMSIに切り替えることができます-フロー。
Note that an S-PMSI Join that is not received over a PMSI (e.g., one that is received directly from a CE) is an illegal packet that MUST be discarded.
PMSIで受信されないS-PMSI結合（たとえば、CEから直接受信されたもの）は、破棄する必要がある違法なパケットであることに注意してください。
The S-PMSI Join message is encapsulated within UDP and has the following type/length/value (TLV) encoding:
S-PMSI結合メッセージはUDP内でカプセル化され、次のタイプ/長さ/値（TLV）エンコードがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits)
タイプ（8ビット）
Length (16 bits): the total number of octets in the Type, Length, and Value fields combined
長さ（16ビット）：タイプ、長さ、および値フィールドのオクテットの総数
Value (variable length)
値（変数長）
In this specification, only one type of S-PMSI Join is defined. A Type 1 S-PMSI Join is used when the S-PMSI tunnel is a PIM tunnel that is used to carry a single multicast stream, where the packets of that stream have IPv4 source and destination IP addresses.
この仕様では、1種類のS-PMSI結合のみが定義されています。S-PMSIトンネルが単一のマルチキャストストリームを運ぶために使用されるPIMトンネルである場合、タイプ1 S-PMSI結合が使用されます。このストリームのパケットにはIPv4ソースと宛先IPアドレスがあります。
The S-PMSI Join format to use when the C-source and C-group are IPv6 addresses will be defined in a follow-on document.
c-sourceとc-groupがIPv6アドレスである場合に使用するS-PMSI結合形式は、後続ドキュメントで定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits): 1
タイプ（8ビット）：1
Length (16 bits): 16
長さ（16ビット）：16
Reserved (8 bits): This field SHOULD be zero when transmitted, and MUST be ignored when received.
予約済み（8ビット）：このフィールドは送信時にゼロである必要があり、受信したときに無視する必要があります。
C-source (32 bits): the IPv4 address of the traffic source in the VPN.
C-Source（32ビット）：VPNのトラフィックソースのIPv4アドレス。
C-group (32 bits): the IPv4 address of the multicast traffic destination address in the VPN.
C-Group（32ビット）：VPNのマルチキャストトラフィックデスティネーションアドレスのIPv4アドレス。
P-group (32 bits): the IPv4 group address that the PE router is going to use to encapsulate the flow (C-source, C-group).
P-Group（32ビット）：IPv4グループは、PEルーターがフローをカプセル化するために使用することを扱います（C-Source、C-Group）。
The P-group identifies the S-PMSI P-tunnel, and the (C-S,C-G) identifies the multicast flow that is carried in the P-tunnel.
PグループはS-PMSI Pトンネルを識別し、（C-S、C-G）はPトンネルで運ばれるマルチキャストフローを識別します。
The protocol uses the following constants.
プロトコルは次の定数を使用します。
[S-PMSI_DELAY]:
[S-PMSI_DELAY]：
Once an S-PMSI Join message has been sent, the PE router that is to transmit onto the S-PMSI will delay this amount of time before it begins using the S-PMSI. The default value is 3 seconds.
S-PMSI結合メッセージが送信されると、S-PMSIに送信するPEルーターは、S-PMSIの使用を開始する前にこの時間を遅らせます。デフォルト値は3秒です。
[S-PMSI_TIMEOUT]:
[s-pmsi_timeout]：
If a PE (other than the transmitter) does not receive any packets over the S-PMSI P-tunnel for this amount of time, the PE will prune itself from the S-PMSI P-tunnel, and will expect (C-S,C-G) packets to arrive on an I-PMSI. The default value is 3 minutes.
PE（送信機以外）がこの時間の間、S-PMSI Pトンネル上のパケットを受け取らない場合、PEはS-PMSI Pトンネルから自らを剪定し、（C-S、C-G）を期待します。I-PMSIに到着するパケット。デフォルト値は3分です。
This value must be consistent among PE routers.
この値は、PEルーター間で一貫している必要があります。
[S-PMSI_HOLDOWN]:
[S-PMSI_HOLDOWN]：
If the PE that transmits onto the S-PMSI does not see any (C-S,C-G) packets for this amount of time, it will resume sending (C-S,C-G) packets on an I-PMSI.
S-PMSIに送信するPEがこの時間の間（C-S、C-G）パケットが表示されない場合、I-PMSIで（C-S、C-G）パケットの送信を再開します。
This is used to avoid oscillation when traffic is bursty. The default value is 1 minute.
これは、トラフィックが破裂したときの振動を回避するために使用されます。デフォルト値は1分です。
[S-PMSI_INTERVAL]:
[S-PMSI_INTERVAL]：
The interval the transmitting PE router uses to periodically send the S-PMSI Join message. The default value is 60 seconds.
送信PEルーターが使用する間隔は、S-PMSI結合メッセージを定期的に送信します。デフォルト値は60秒です。
S-PMSIs can be aggregated on a P-multicast tree. The S-PMSI to (C-S,C-G) binding advertisement supports aggregation. Furthermore, the aggregation procedures of Section 6.3 apply. It is also possible to aggregate both S-PMSIs and I-PMSIs on the same P-multicast tree.
S-PMSISは、P-Multicastツリーに集約できます。S-PMSIから（C-S、C-G）結合広告は集約をサポートします。さらに、セクション6.3の集約手順が適用されます。S-PMSISとI-PMSISの両方を同じP-Multicastツリーに集約することも可能です。
If an MVPN has sites in more than one AS, it requires one or more PMSIs to be instantiated by inter-AS P-tunnels. This document describes two different types of inter-AS P-tunnel:
MVPNが複数のASでサイトを持っている場合、1つ以上のPMSIをP-Tunnel間でインスタンス化する必要があります。このドキュメントでは、2つの異なるタイプのP-tunnelを説明しています。
1. "Segmented inter-AS P-tunnels"
1. 「P-Tunnelsとしてのセグメント化されたインターインター」
A segmented inter-AS P-tunnel consists of a number of independent segments that are stitched together at the ASBRs. There are two types of segment: inter-AS segments and intra-AS segments. The segmented inter-AS P-tunnel consists of alternating intra-AS and inter-AS segments.
P-Tunnelのセグメント化されたInter-AS P-Tunnelは、ASBRSで一緒に縫い合わされた多くの独立したセグメントで構成されています。セグメントには、セグメント間とセグメント内のセグメントの2つのタイプがあります。セグメント化されたP-tunnelは、AS内およびAS間のセグメントを交互に行うことで構成されています。
Inter-AS segments connect adjacent ASBRs of different ASes; these "one-hop" segments are instantiated as unicast P-tunnels.
ASセグメント間は、異なるASEの隣接するASBRを接続します。これらの「ワンホップ」セグメントは、ユニキャストPタンネルとしてインスタンス化されています。
Intra-AS segments connect ASBRs and PEs that are in the same AS. An intra-AS segment may be of whatever technology is desired by the SP that administers the that AS. Different intra-AS segments may be of different technologies.
Intra-As Segmentは、同じものと同じASBRとPEを接続します。ASのイントラセグメントは、そのASを管理するSPが望んでいる技術のものである場合があります。さまざまなセグメントは、さまざまなテクノロジーのものである可能性があります。
Note that the intra-AS segments of inter-AS P-tunnels form a category of P-tunnels that is distinct from simple intra-AS P-tunnels; we will rely on this distinction later (see Section 9).
P-Tunnels間のセグメントは、単純なP-Tunnelsとは異なるPタンネルのカテゴリを形成することに注意してください。後でこの区別に依存します（セクション9を参照）。
A segmented inter-AS P-tunnel can be thought of as a tree that is rooted at a particular AS, and that has, as its leaves, the other ASes that need to receive multicast data from the root AS.
P-tunnelのセグメント化されたInter-as P-tunnelは、特定のAsに根ざした木と考えることができます。葉として、ルートからマルチキャストデータを受け取る必要がある他のASがあります。
2. "Non-segmented Inter-AS P-tunnels"
2. 「非セグメント化されていないp-tunnels」
A non-segmented inter-AS P-tunnel is a single P-tunnel that spans AS boundaries. The tunnel technology cannot change from one point in the tunnel to the next, so all ASes through which the P-tunnel passes must support that technology. In essence, AS boundaries are of no significance to a non-segmented inter-AS P-tunnel.
非セグメント化されたP-tunnelは、境界として範囲の単一のPトンネルです。トンネル技術はトンネルのあるポイントから次のポイントに変更することはできないため、Pトンネルが通過するすべてのASEはその技術をサポートする必要があります。本質的に、境界はP-tunnelの非セグメント化されていない間で意味がないためです。
Section 10 of [RFC4364] describes three different options for supporting unicast inter-AS BGP/MPLS IP VPNs, known as options A, B, and C. We describe below how both segmented and non-segmented inter-AS trees can be supported when options B or C are used. (Option A does not pass any routing information through an ASBR at all, so no special inter-AS procedures are needed.)
[RFC4364]のセクション10では、オプションA、B、およびCとして知られるUnicast Inter-AS BGP/MPLS IP VPNをサポートするための3つの異なるオプションについて説明します。オプションBまたはCが使用されます。（オプションAはASBRを介してルーティング情報をまったく渡さないため、特別なAS Inter-AS手順は必要ありません。）
In this model, the previously described discovery and tunnel setup mechanisms are used, even though the PEs belonging to a given MVPN may be in different ASes.
このモデルでは、特定のMVPNに属するPEが異なる可能性がある場合でも、前述の発見およびトンネルセットアップメカニズムが使用されます。
The previously described BGP-based auto-discovery mechanisms work "as is" when an MVPN contains PEs that are in different Autonomous Systems. However, please note that, if non-segmented inter-AS P-tunnels are to be used, then the Intra-AS I-PMSI A-D routes MUST be distributed across AS boundaries!
前述のBGPベースの自動発見メカニズムは、MVPNに異なる自律システムにあるPESが含まれている場合、「現状のまま」に機能します。ただし、P-Tunnelsを使用していない場合は、INTRA-AS I-PMSI A-Dルートを境界として分布する必要があることに注意してください。
When non-segmented inter-AS P-tunnels are used, MVPN C-multicast routing information may be exchanged by means of PIM peering across an MI-PMSI or by means of BGP carrying C-multicast routes.
非セグメント化されたP-tunnelsを使用すると、MVPN Cマルチキャストルーティング情報は、Mi-PMSIを介してPIMを覗くことによって、またはCマルチキャストルートを運ぶBGPによって交換されます。
When PIM peering is used to distribute the C-multicast routing information, a PE that sends C-PIM Join/Prune messages for a particular (C-S,C-G) must be able to identify the PE that is its PIM adjacency on the path to S. This is the "Selected Upstream PE" described in Section 5.1.3.
PIMピアリングを使用してC-Multicastルーティング情報を配布する場合、特定の（C-S、C-G）にC-PIM Join/Pruneメッセージを送信するPEは、Sへのパス上のPIM隣接能力であるPEを識別できる必要があります。。これは、セクション5.1.3で説明されている「選択された上流のPE」です。
If BGP (rather than PIM) is used to distribute the C-multicast routing information, and if option b of Section 10 of [RFC4364] is in use, then the C-multicast routes will be installed in the ASBRs along the path from each multicast source in the MVPN to each multicast receiver in the MVPN. If option b is not in use, the C-multicast routes are not installed in the ASBRs. The handling of the C-multicast routes in either case is thus exactly analogous to the handling of unicast VPN-IP routes in the corresponding case.
BGP（PIMではなく）を使用してC-Multicastルーティング情報を配布し、[RFC4364]のセクション10のオプションBが使用されている場合、C-Multicastルートはそれぞれのパスに沿ってASBRにインストールされます。MVPNのMVPNのマルチキャストソースは、MVPNの各マルチキャストレシーバーに。オプションBが使用されていない場合、C-MulticastルートはASBRSにインストールされていません。したがって、どちらの場合でもCマルチキャストルートの取り扱いは、対応する場合のユニキャストVPN-IPルートの取り扱いにまったく類似しています。
The procedures described earlier in this document can be used to instantiate either an I-PMSI or an S-PMSI with inter-AS P-tunnels. Specific tunneling techniques require some explanation.
このドキュメントで前述した手順は、I-PMSIまたはS-PMSIをPS-Inter-AS P-Tunnelsのいずれかをインスタンス化するために使用できます。特定のトンネリング技術には、何らかの説明が必要です。
If ingress replication is used, the inter-AS PE-PE P-tunnels will use the inter-AS tunneling procedures for the tunneling technology used.
イングレスレプリケーションを使用すると、PE-PE PE PE-PE PE-Tunnelsは、使用されるトンネリング技術のトンネル間手順を使用します。
Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP P-tunnels.
[RSVP-P2MP]の手順は、RSVP-TE P2MP P2MP P-Tunnelsとして使用されます。
Procedures for using PIM to set up the P-tunnels are discussed in the next section.
PIMを使用してPタンネルをセットアップする手順については、次のセクションで説明します。
When PIM is used to set up a non-segmented inter-AS P-multicast tree, the PIM Join/Prune messages used to join the tree contain the IP address of the Upstream PE. However, there are two special considerations that must be taken into account:
PIMを使用して、セグメント化されていないP-Multicastツリーを設定する場合、ツリーに参加するために使用されるPIM結合/プルーンメッセージには、上流のPEのIPアドレスが含まれます。ただし、考慮する必要がある2つの特別な考慮事項があります。
- It is possible that the P routers within one or more of the ASes will not have routes to the Upstream PE. For example, if an AS has a "BGP-free core", the P routers in an AS will not have routes to addresses outside the AS.
- ASEの1つ以上のPルーターには、上流のPEへのルートがない可能性があります。たとえば、ASが「BGPフリーコア」を備えている場合、ASのPルーターにはASの外側のアドレスへのルートがありません。
- If the PIM Join/Prune message must travel through several ASes, it is possible that the ASBRs will not have routes to he PE routers. For example, in an inter-AS VPN constructed according to "option b" of Section 10 of [RFC4364], the ASBRs do not necessarily have routes to the PE routers.
- PIM結合/プルーンメッセージがいくつかのASEを通過する必要がある場合、ASBRSにはHE PEルーターへのルートがない可能性があります。たとえば、[RFC4364]のセクション10の「オプションB」に従って構築されたAS Inter-AS VPNでは、ASBRには必ずしもPEルーターへのルートがありません。
In either case, "ordinary" PIM Join/Prune messages cannot be routed to the Upstream PE. Therefore, in that case, the PIM Join/Prune messages MUST contain the "PIM MVPN Join attribute". This allows the multicast distribution tree to be properly constructed, even if routes to PEs in other ASes do not exist in the given AS's IGP and
どちらの場合でも、「通常の」PIM結合/プルーンメッセージを上流のPEにルーティングすることはできません。したがって、その場合、PIM結合/プルーンメッセージには「PIM MVPN JOIN属性」を含める必要があります。これにより、他のASEのPESへのルートが与えられたASのIGPに存在しない場合でも、マルチキャスト分布ツリーを適切に構築できます。
even if the routes to those PEs do not exist in BGP. The use of a PIM MVPN Join attribute in the PIM messages allows the inter-AS trees to be built.
これらのPEへのルートがBGPに存在しなくても。PIMメッセージでPIM MVPN結合属性を使用すると、AS Inter-ASツリーを構築できます。
The PIM MVPN Join attribute adds the following information to the PIM Join/Prune messages: a "proxy address", which contains the address of the next ASBR on the path to the Upstream PE. When the PIM Join/Prune arrives at the ASBR that is identified by the "proxy address", that ASBR must change the proxy address to identify the next hop ASBR.
PIM MVPN JOIN属性は、次の情報をPIM Join/Pruneメッセージに追加します。「プロキシアドレス」には、上流のPEへのパス上の次のASBRのアドレスが含まれています。PIMの結合/Pruneが「プロキシアドレス」によって識別されるASBRに到着すると、ASBRは次のホップASBRを識別するためにプロキシアドレスを変更する必要があります。
This information allows the PIM Join/Prune to be routed through an AS, even if the P routers of that AS do not have routes to the Upstream PE. However, this information is not sufficient to enable the ASBRs to route the Join/Prune if the ASBRs themselves do not have routes to the Upstream PE.
この情報により、PIMの結合/プルーンをASを介してルーティングできます。ただし、ASBR自体に上流のPEへのルートがない場合、ASBRが結合/プルーンをルーティングできるようにするには、この情報は十分ではありません。
However, even if the ASBRs do not have routes to the Upstream PE, the procedures of this document ensure that they will have Intra-AS I-PMSI A-D routes that lead to the Upstream PE. (Recall that if non-segmented inter-AS P-tunnels are being used, the ASBRs and PEs will have Intra-AS I-PMSI A-D routes that have been distributed inter-AS.)
ただし、ASBRに上流のPEへのルートがない場合でも、このドキュメントの手順により、上流のPEにつながるI-PMSI A-Dルートがあることが保証されます。（P-Tunnelsを使用していないセグメント化されていない場合、ASBRSとPESにはINTRA-AS IPMSI A-Dルートがあることを思い出してください。
So, rather than having the PIM Join/Prune messages routed by the ASBRs along a route to the Upstream PE, the PIM Join/Prune messages MUST be routed along the path determined by the Intra-AS I-PMSI A-D routes.
したがって、ASBRによって上流のPEへのルートに沿ってルーティングされたPIM結合/プルーンメッセージを搭載するのではなく、PIM結合/プルーンメッセージは、I-PMSI A-Dルートで決定されたパスに沿ってルーティングする必要があります。
The basic format of a PIM Join attribute is specified in [PIM-ATTRIB]. The details of the PIM MVPN Join attribute are specified in the next section.
PIM結合属性の基本形式は[PIM-Attrib]で指定されています。PIM MVPN結合属性の詳細は、次のセクションで指定されています。
In [PIM-ATTRIB], the notion of a "join attribute" is defined, and a format for included join attributes in PIM Join/Prune messages is specified. We now define a new join attribute, which we call the "MVPN Join attribute".
[Pim-Attrib]では、「結合属性」の概念が定義されており、PIM Join/Pruneメッセージに含まれる結合属性の形式が指定されています。次に、「MVPN Join Attribute」と呼ばれる新しいJoin属性を定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Proxy IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
The Attr_Type field of the MVPN Join attribute is set to 1.
MVPN JOIN属性のATTR_TYPEフィールドは1に設定されています。
The F bit is set to 0.
Fビットは0に設定されています。
Two information fields are carried in the MVPN Join attribute:
MVPN結合属性に2つの情報フィールドが携帯されています。
- Proxy IP address: The IP address of the node towards which the PIM Join/Prune message is to be forwarded. This will be either an IPv4 or an IPv6 address, depending on whether the PIM Join/Prune message itself is IPv4 or IPv6.
- プロキシIPアドレス：PIMが結合/プルーンメッセージを転送するノードのIPアドレスを転送します。これは、PIM結合/プルーンメッセージ自体がIPv4またはIPv6であるかどうかに応じて、IPv4またはIPv6アドレスのいずれかです。
- RD: An eight-byte RD. This immediately follows the proxy IP address.
- RD：8バイトRD。これは、プロキシIPアドレスのすぐ後になります。
The PIM message also carries the address of the Upstream PE.
PIMメッセージには、上流のPEのアドレスも搭載されています。
In the case of an intra-AS MVPN, the proxy and the Upstream PE are the same. In the case of an inter-AS MVPN, the proxy will be the ASBR that is the exit point from the local AS on the path to the Upstream PE.
MVPN内の場合、プロキシと上流のPEは同じです。MVPN間の場合、プロキシは、上流のPEへのパスのようにローカルからの出口ポイントであるASBRになります。
When a PE router originates a PIM Join/Prune message in order to set up an inter-AS PMSI, it does so as a result of having received a particular Intra-AS I-PMSI A-D route or S-PMSI A-D route. It includes an MVPN Join attribute whose fields are set as follows:
PEルーターがPMSIをAS Inter-AS ASを設定するためにPIM結合/プルーンメッセージを発信する場合、IPMSI AS INTRA-INTRA-SPMSI A-Dルートを受け取った結果としてそうします。これには、フィールドが次のように設定されているMVPN結合属性が含まれます。
- If the Upstream PE is in the same AS as the local PE, then the proxy field contains the address of the Upstream PE. Otherwise, it contains the address of the BGP Next Hop of the route to the Upstream PE.
- 上流のPEがローカルPEと同じである場合、プロキシフィールドには上流のPEのアドレスが含まれます。それ以外の場合は、上流のPEへのルートのBGP次のホップのアドレスが含まれています。
- The RD field contains the RD from the NLRI of the Intra-AS A-D route.
- RDフィールドには、A-Dルート内のNLRIからのRDが含まれています。
- The Upstream PE field contains the address of the PE that originated the Intra-AS I-PMSI A-D route or S-PMSI A-D route (obtained from the NLRI of that route).
- 上流のPEフィールドには、I-PMSI A-DルートまたはS-PMSI A-Dルート（そのルートのNLRIから取得）を発信したPEのアドレスが含まれています。
When a PIM router processes a PIM Join/Prune message with an MVPN Join attribute, it first checks to see if the proxy field contains one of its own addresses.
PIMルーターがMVPN Join属性を使用してPIM結合/プルーンメッセージを処理する場合、最初にプロキシフィールドに独自のアドレスの1つが含まれているかどうかを確認します。
If not, the router uses the proxy IP address in order to determine the RPF interface and neighbor. The MVPN Join attribute must be passed upstream unchanged.
そうでない場合、ルーターはRPFインターフェイスとネイバーを決定するためにプロキシIPアドレスを使用します。MVPN結合属性は、変更されていない上流に渡す必要があります。
If the proxy address is one of the router's own IP addresses, then the router looks in its BGP routing table for an Intra-AS A-D route whose NLRI consists of the Upstream PE address prepended with the RD from the Join attribute. If there is no match, the PIM message is discarded. If there is a match, the IP address from the BGP next hop field of the matching route is used in order to determine the RPF interface and neighbor. When the PIM Join/Prune is forwarded upstream, the proxy field is replaced with the address of the BGP next hop, and the RD and Upstream PE fields are left unchanged.
プロキシアドレスがルーター自身のIPアドレスの1つである場合、ルーターはBGPルーティングテーブルを調整し、NLRIがJoin属性からRDで準備されている上流のPEアドレスで構成されているA-DルートのAS A-Dルートを調べます。一致しない場合、PIMメッセージは破棄されます。一致がある場合、RPFインターフェイスと隣接を決定するために、一致ルートのBGP次のホップフィールドからのIPアドレスが使用されます。PIM結合/プルーンが上流に転送されると、プロキシフィールドはBGP Next Hopのアドレスに置き換えられ、RDおよび上流のPEフィールドは変更されません。
The use of non-segmented inter-AS trees constructed via BIDIR-PIM is outside the scope of this document.
Bidir-PIMを介して構築された非セグメント化されたAS間のAS間の使用は、このドキュメントの範囲外です。
The procedures for setting up and maintaining segmented inter-AS Inclusive and Selective P-tunnels may be found in [MVPN-BGP].
セグメント化された包括的および選択的なpターンネルをセットアップおよび維持する手順は、[MVPN-BGP]に記載されている場合があります。
Consider the case of an egress PE that receives packets of a particular C-flow, (C-S,C-G), over a non-aggregated S-PMSI. The procedures described so far will never cause the PE to receive duplicate copies of any packet in that stream. It is possible that the (C-S,C-G) stream is carried in more than one S-PMSI; this may happen when the site that contains C-S is multihomed to more than one PE. However, a PE that needs to receive (C-S,C-G) packets only joins one of these S-PMSIs, and so it only receives one copy of each packet. However, if the data packets of stream (C-S,C-G) are carried in either an I-PMSI or an aggregated S-PMSI, then the procedures specified so far make it possible for an egress PE to receive more than one copy of each data packet. Additional procedures are needed to either make this impossible or ensure that the egress PE does not forward duplicates to the CE routers.
凝集していないS-PMSIを介して、特定のCフロー（C-S、C-G）のパケットを受信する出力PEの場合を考えてみましょう。これまでに説明されている手順により、PEがそのストリーム内のパケットの重複コピーを受け取ることはありません。（C-S、C-G）ストリームが複数のS-PMSIで運ばれる可能性があります。これは、C-Sを含むサイトが複数のPEにマルチホームされている場合に発生する可能性があります。ただし、（C-S、C-G）パケットを受信する必要があるPEは、これらのS-PMSIの1つのみに結合するため、各パケットの1つのコピーのみを受信します。ただし、ストリームのデータパケット（C-S、C-G）がI-PMSIまたは集約されたS-PMSIのいずれかで運ばれている場合、これまでに指定された手順により、出力PEが各データの複数のコピーを受信できるようになります。パケット。これを不可能にするか、出力PEがCEルーターに重複を転送しないことを確認するには、追加の手順が必要です。
This section covers only the situation where the C-trees are unidirectional, in either the ASM or SSM service models. The case where the C-trees are bidirectional is considered separately in Section 11.
このセクションでは、ASMまたはSSMサービスモデルのいずれかで、Cツリーが単方向である状況のみをカバーしています。Cツリーが双方向である場合は、セクション11で別々に考慮されます。
There are two cases where the procedures specified so far make it possible for an egress PE to receive duplicate copies of a multicast data packet. These are as follows:
これまでに指定された手順により、出力PEがマルチキャストデータパケットの重複コピーを受け取ることができる2つのケースがあります。これらは次のとおりです。
1. The first case occurs when both of the following conditions hold:
1. 最初のケースは、次の両方の条件が当てはまる場合に発生します。
a. an MVPN site that contains C-S or C-RP is multihomed to more than one PE, and
a. C-SまたはC-RPを含むMVPNサイトは複数のPEにマルチホームされています。
b. either an I-PMSI or an aggregated S-PMSI is used for carrying the packets originated by C-S.
b. I-PMSIまたは集約されたS-PMSIのいずれかが、C-Sから発生したパケットを運ぶために使用されます。
In this case, an egress PE may receive one copy of the packet from each PE to which the site is homed. This case is discussed further in Section 9.2.
この場合、出力PEは、サイトが住む各PEからパケットのコピーを1つ受け取ることができます。このケースについては、セクション9.2でさらに説明します。
2. The second case occurs when all of the following conditions hold:
2. 2番目のケースは、次のすべての条件が保持されている場合に発生します。
a. the IP destination address of the customer packet, C-G, identifies a multicast group that is operating in ASM mode and whose C-multicast tree is set up using PIM-SM,
a. 顧客パケットのIP宛先アドレスC-Gは、ASMモードで動作し、そのC-MulticastツリーがPIM-SMを使用してセットアップされているマルチキャストグループを識別します。
b. an MI-PMSI is used for carrying the data packets, and
b. Mi-PMSIは、データパケットを運ぶために使用され、
c. a router or a CE in a site connected to the egress PE switches from the C-RP tree to the C-S tree.
c. 出力に接続されたサイトのルーターまたはCEは、C-RPツリーからC-Sツリーに切り替えます。
In this case, it is possible to get one copy of a given packet from the ingress PE attached to the C-RP's site and one from the ingress PE attached to the C-S's site. This case is discussed further in Section 9.3.
この場合、C-RPのサイトに接続されたIngress PEから、特定のパケットのコピーを1つ、C-Sのサイトに接続されたIngress PEから取得することができます。このケースについては、セクション9.3でさらに説明します。
Additional procedures are therefore needed to ensure that no MVPN customer sees steady state multicast data packet duplication. There are three procedures that may be used:
したがって、MVPNの顧客が定常状態のマルチキャストデータパケットの複製を見ないようにするには、追加の手順が必要です。使用できる3つの手順があります。
1. Discarding data packets received from the "wrong" PE
1. 「間違った」PEから受信したデータパケットの破棄
2. Single Forwarder Selection
2. 単一のフォワーダーの選択
3. Native PIM methods
3. ネイティブPIMメソッド
These methods are described in Section 9.1. Their applicability to the two scenarios where duplication is possible is discussed in Sections 9.2 and 9.3.
これらの方法は、セクション9.1で説明されています。重複が可能な2つのシナリオへの適用性については、セクション9.2および9.3で説明しています。
Every MVPN MUST use at least one of the three methods for ensuring non-duplication.
すべてのMVPNは、非重複を確保するために3つの方法のうち少なくとも1つを使用する必要があります。
Per Section 5.1.3, an egress PE, say PE1, chooses a specific Upstream PE, for given (C-S,C-G). When PE1 receives a (C-S,C-G) packet from a PMSI, it may be able to identify the PE that transmitted the packet onto the PMSI. If that transmitter is other than the PE selected by PE1 as the Upstream PE, then PE1 can drop the packet. This means that the PE will see a duplicate, but the duplicate will not get forwarded.
セクション5.1.3ごとに、たとえばPE1などの出口PEは、与えられた（C-S、C-G）に対して特定の上流のPEを選択します。PE1がPMSIから（C-S、C-G）パケットを受信すると、パケットをPMSIに送信したPEを識別できる場合があります。その送信機が上流のPEとしてPE1によって選択されたPE以外の場合、PE1はパケットをドロップできます。これは、PEが重複していることを意味しますが、重複は転送されません。
The method used by an egress PE to determine the ingress PE for a particular packet, received over a particular PMSI, depends on the P-tunnel technology that is used to instantiate the PMSI. If the P-tunnel is a P2MP LSP, a PIM-SM or PIM-SSM tree, or a unicast P-tunnel that uses IP encapsulation, then the tunnel encapsulation contains information that can be used (possibly along with other state information in the PE) to determine the ingress PE, as long as the P-tunnel is instantiating an intra-AS PMSI or an inter-AS PMSI which is supported by a non-segmented inter-AS tunnel.
特定のPMSIを介して受信した特定のパケットの侵入PEを決定するために出口PEが使用する方法は、PMSIをインスタンス化するために使用されるPトンネル技術に依存します。PトンネルがP2MP LSP、PIM-SMまたはPIM-SSMツリー、またはIPカプセル化を使用するユニキャストPトンネルである場合、トンネルのカプセル化には使用できる情報が含まれています（おそらく、他の状態情報と一緒にPE）P-tunnelがPMSIまたはInter-as PMSIをインストラしている限り、セグメント化されていないトンネルによってサポートされているPMSIを決定します。
Even when inter-AS segmented P-tunnels are used, if an aggregated S-PMSI is used for carrying the packets, the tunnel encapsulation must have some information that can be used to identify the PMSI; in turn, that implicitly identifies the ingress PE.
セグメント化されたP-tunnelを使用している場合でも、集約されたS-PMSIがパケットの運搬に使用されている場合、トンネルのカプセル化にはPMSIを識別するために使用できる情報が必要です。次に、それはイングレスPEを暗黙的に識別します。
Consider the case of an I-PMSI that spans multiple ASes and that is instantiated by segmented inter-AS P-tunnels. Suppose it is carrying data that is traveling along a particular C-tree. Suppose also that the C-root of that C-tree is multihomed to two or more PEs, and that each such PE is in a different AS than the others. Then, if there is any duplicate traffic, the duplicates will arrive on a different P-tunnel. Specifically, if the PE was expecting the traffic on a particular inter-AS P-tunnel, duplicate traffic will arrive either on an intra-AS P-tunnel (not an intra-AS segment of an inter-AS P-tunnel) or on some other inter-AS P-tunnel. To detect duplicates, the PE has to keep track of which inter-AS A-D route the PE uses for sending MVPN multicast routing information towards the C-S/C-RP. The PE MUST process received (multicast) traffic originated by C-S/C-RP only from the inter-AS P-tunnel that was carried in the best Inter-AS A-D route for the MVPN and that was originated by the AS that contains C-S/C-RP (where "the best" is determined by the PE). The PE MUST discard, as duplicates, all other multicast traffic originated by the C-S/C-RP, but received on any other P-tunnel.
複数のASEに及ぶI-PMSIの場合を考えてみましょう。特定のCツリーに沿って移動しているデータを伝達しているとします。また、そのc-TreeのCルートが2つ以上のPEにマルチホームされており、そのようなPEはそれぞれ他のPEとは異なると仮定します。次に、重複するトラフィックがある場合、複製は別のPトンネルに到着します。具体的には、PEが特定のPトンネル間のトラフィックを期待していた場合、重複するトラフィックは、Pトンネル内（Inter-As As P-Tunnelのセグメントではなく）または上に到着します。他のいくつかのP-tunnel間。重複を検出するには、PEは、MVPNマルチキャストルーティング情報をC-S/C-RPに送信するためにPEが使用するA-Dルート間でどのA-Dルートを実行するかを追跡する必要があります。 PEは、MVPNに最適なA-Dルートで運ばれ、C-S/を含むASによって発生するAS P-TunnelからのみC-S/C-RPが発信する受信（マルチキャスト）トラフィックを処理する必要があります。 C-RP（ここで、「最高」はPEによって決定されます）。 PEは、重複するように、他のすべてのマルチキャストトラフィックがC-S/C-RPによって発生したが、他のPトンネルで受信する必要があります。
If, for a given MVPN, (a) an MI-PMSI is used for carrying multicast data packets, (b) the MI-PMSI is instantiated by a segmented inter-AS P-tunnel, (c) the C-S or C-RP is multihomed to different PEs, and (d) at least two such PEs are in the same AS, then, depending on the
特定のMVPNの場合、（a）マルチキャストデータパケットの運搬にMi-PMSIが使用される場合、（b）Mi-PMSIは、P-Tunnelのセグメント化されたP-Tunnelによってインスタンス化され、（c）C-SまたはC-RPによってインスタンス化されます。異なるPEにマルチホームされており、（d）少なくとも2つのそのようなPEは、と同じです。
tunneling technology used to instantiate the MI-PMSI, it may not always be possible for the egress PE to determine the Upstream PE. In that case, the procedure of Sections 9.1.2 or 9.1.3 must be used.
Mi-PMSIをインスタンス化するために使用されるトンネル技術は、出口PEが上流のPEを決定することが常に可能ではない場合があります。その場合、セクション9.1.2または9.1.3の手順を使用する必要があります。
NB: Section 10 describes an exception case where PE1 has to accept a packet even if it is not from the Selected Upstream PE.
NB：セクション10では、選択した上流のPEからではない場合でも、PE1がパケットを受け入れる必要がある例外ケースについて説明します。
Section 5.1 specifies a procedure for choosing a "default Upstream PE selection", such that (except during routing transients) all PEs will choose the same default Upstream PE. To ensure that duplicate packets are not sent through the backbone (except during routing transients), an ingress PE does not forward to the backbone any (C-S,C-G) multicast data packet it receives from a CE, unless the PE is the default Upstream PE selection.
セクション5.1は、「デフォルトのアップストリームPE選択」を選択する手順を指定します。これにより、（ルーティングトランジェント中を除く）すべてのPEが同じデフォルトのアップストリームPEを選択します。複製パケットがバックボーンを介して送信されないようにするため（ルーティングトランジェント中に）、侵入PEはバックボーンに転送しません（C-S、C-G）マルチキャストデータパケットは、PEがデフォルトのアップストリームPEでない限り、CEから受信します。選択。
One difference in effect between this procedure and the procedure of Section 9.1.1 is that this procedure sends only one copy of each packet to each egress PE, rather than sending multiple copies and forcing the egress PE to discard all but one.
この手順とセクション9.1.1の手順との効果の1つの違いは、この手順では、複数のコピーを送信し、Eugress PEに1つ以外のすべてを廃棄するように強制するのではなく、各出力PEに各パケットのコピーを1つだけ送信することです。
If PE-PE multicast routing information for a given MVPN is being disseminated by running PIM over an MI-PMSI, then native PIM methods will prevent steady state data packet duplication. The PIM Assert mechanism prevents steady state duplication in the scenario of Section 9.2, even if Single Forwarder Selection is not done. The PIM Prune(S,G,rpt) mechanism addresses the scenario of Section 9.3.
特定のMVPNのPE-PEマルチキャストルーティング情報がMi-PMSIを介してPIMを実行することにより普及している場合、ネイティブPIMメソッドは定常状態データパケットの複製を防ぎます。PIMアサートメカニズムは、単一のフォワーダーの選択が行われていなくても、セクション9.2のシナリオで定常状態の重複を防ぎます。PIM Prune（S、G、RPT）メカニズムは、セクション9.3のシナリオに対処しています。
Any of the three methods of Section 9.1 will prevent steady state duplicates in the case of a multihomed C-S or C-RP.
セクション9.1の3つの方法のいずれかは、マルチホームC-SまたはC-RPの場合、定常状態の重複を防ぎます。
If some PEs are on the C-S tree and some are on the C-RP tree, then a PE may also receive duplicate data traffic after a (C-*,C-G) to (C-S,C-G) switch.
一部のPEがC-Sツリーにあり、一部はC-RPツリーにある場合、PEは（C-*、C-G）から（C-S、C-G）スイッチの後に重複したデータトラフィックを受け取ることもあります。
If PIM is being used on an MI-PMSI to disseminate multicast routing information, native PIM methods (in particular, the use of the Prune(S,G,rpt) message) prevent steady state data duplication in this case.
マルチキャストルーティング情報を広めるためにMi-PMSIでPIMが使用されている場合、ネイティブPIMメソッド（特に、Prune（S、G、RPT）の使用）が安定した状態データの複製を防ぎます。
If BGP C-multicast routing is being used, then the procedure of Section 9.1.1, if applicable, can be used to prevent duplication. However, if that procedure is not applicable, then the procedure of Section 9.1.2 is not sufficient to prevent steady state data duplication in all scenarios.
BGP C-Multicastルーティングが使用されている場合、該当する場合は、セクション9.1.1の手順を使用して重複を防ぐことができます。ただし、その手順が適用されない場合、セクション9.1.2の手順は、すべてのシナリオで定常状態データの複製を防ぐのに十分ではありません。
In the scenario in which (a) BGP C-multicast routing is being used, (b) there are inter-site shared C-trees, and (c) there are inter-site source C-trees, additional procedures are needed. To see this, consider the following topology:
（a）BGP C-Multicastルーティングが使用されているシナリオでは、（b）間隔共有Cツリーがあり、（c）敷地間ソースCツリーがあり、追加手順が必要です。これを見るには、次のトポロジーを検討してください。
CE1---C-RP | | CE2---PE1-- ... --PE2---CE5---C-S ... C-R1---CE3---PE3-- ... --PE4---CE4---C-R2
CE1 --- C-RP ||CE2 --- PE1-- ... - PE2 --- CE5 --- C-S ... C-R1 --- CE3--- PE3-- ... - PE4 --- CE4 ---C-R2
Suppose that C-R1 and C-R2 use PIM to join the (C-*,C-G) tree, where C-RP is the RP corresponding to C-G. As a result, CE3 and CE4 will send PIM Join(*,G) messages to PE3 and PE4, respectively. This will cause PE3 and PE4 to originate C-multicast Shared Tree Join Routes, specifying (C-*,C-G). These routes will identify PE1 as the Upstream PE.
C-R1とC-R2がPIMを使用して（C - *、C-G）ツリーに結合し、C-RPがC-Gに対応するRPに結合するとします。その結果、CE3とCE4はPIM結合（*、G）メッセージをそれぞれPE3とPE4に送信します。これにより、PE3とPE4がC-Multicastの共有ツリー結合ルートを発信し、（C - *、C-G）を指定します。これらのルートは、PE1を上流のPEとして識別します。
Now suppose that C-S is a transmitter for multicast group C-G, and that C-S sends its multicast data packets to C-RP in PIM Register messages. Then, PE1 will receive (C-S,C-G) data packets from CE1, and will forward them over an I-PMSI to PE3 and PE4, who will forward them, in turn, to CE3 and CE4, respectively.
C-SがマルチキャストグループC-Gの送信機であり、C-SがマルチキャストデータパケットをPIMレジスタメッセージでC-RPに送信すると仮定します。次に、PE1はCE1から（C-S、C-G）データパケットを受け取り、I-PMSIを介してPE3とPE4に転送し、それぞれCE3とCE4に転送します。
When C-R1 receives (C-S,C-G) data packets, it may decide to join the (C-S,C-G) source tree, by sending a PIM Join(S,G) to CE3. This will, in turn, cause CE3 to send a PIM Join(S,G) to PE3, which will, in turn, cause PE3 to originate a C-multicast Source Tree Join Route, specifying (C-S,C-G) and identifying PE2 as the Upstream PE. As a result, when PE2 receives (C-S,C-G) data packets from CE5, it will forward them on a PMSI to PE3.
C-R1が（C-S、C-G）データパケットを受信すると、PIM結合（S、G）をCE3に送信することにより、（C-S、C-G）ソースツリーに結合することを決定する場合があります。これにより、CE3はPIM結合（S、G）をPE3に送信します。これにより、PE3はC-Multicastソースツリーの結合ルートを発信し、（C-S、C-G）を指定し、PE2を特定し、PE2を識別します。上流のPE。その結果、PE2がCE5から（C-S、C-G）データパケットを受信すると、PMSIでPE3に転送されます。
At this point, the following situation exists:
この時点で、次の状況が存在します。
- If PE1 receives (C-S,C-G) packets from CE1, PE1 must forward them on the I-PMSI, because PE4 is still expecting to receive the (C-S,C-G) packets from PE1.
- PE1がCE1から（C-S、C-G）パケットを受信した場合、PE4はPE1から（C-S、C-G）パケットを受け取ることを期待しているため、PE1がI-PMSIに転送する必要があります。
- PE3 must continue to receive packets from the I-PMSI, since there may be other sources transmitting C-G traffic and PE3 currently has no other way to receive that traffic.
- PE3は、C-Gトラフィックを送信する他のソースがある可能性があり、PE3がそのトラフィックを受け取る他の方法がないため、PE3はI-PMSIから引き続きパケットを受け取る必要があります。
- PE3 must also receive (C-S,C-G) traffic from PE2.
- PE3は、PE2から（C-S、C-G）トラフィックも受信する必要があります。
As a result, PE3 may receive two copies of each (C-S,C-G) packet. The procedure of Section 9.1.2 (Single Forwarder Selection) does not prevent PE3 from receiving two copies, because it does not prevent one PE from forwarding (C-S,C-G) traffic along the shared C-tree while another forwards (C-S,C-G) traffic along a source-specific C-tree.
その結果、PE3はそれぞれ（C-S、C-G）パケットの2つのコピーを受け取る場合があります。セクション9.1.2（単一のフォワーダーの選択）の手順では、PE3が2つのコピーを受信することを妨げません。これは、1つのPEが共有Cツリーに沿って転送（C-S、C-G）トラフィックを妨げないため、別のフォワード（C-S、C-G）ソース固有のCツリーに沿ったトラフィック。
So if PE3 cannot apply the method of Section 9.1.1 (Discarding Packets from Wrong PE), perhaps because the tunneling technology does not allow the egress PE to identify the ingress PE, then additional procedures are needed.
したがって、PE3がセクション9.1.1の方法（間違ったPEからパケットを破棄する）を適用できない場合、おそらくトンネリング技術により出口PEが侵入PEを識別できないため、追加の手順が必要です。
The issue described in Section 9.3.1 is resolved through the use of Source Active A-D routes. In the remainder this section, we provide an example of how this works, along with an informal description of the procedures.
セクション9.3.1で説明されている問題は、ソースアクティブA-Dルートを使用して解決されます。残りのセクションでは、手順の非公式の説明とともに、これがどのように機能するかの例を示します。
A full and precise specification of the relevant procedures can be found in Section 13 of [MVPN-BGP]. In the event of any conflicts or other discrepancies between the description below and the description in [MVPN-BGP], [MVPN-BGP] is to be considered to be the authoritative document.
関連する手順の完全かつ正確な仕様は、[MVPN-BGP]のセクション13に記載されています。以下の説明と[MVPN-BGP]の説明と[MVPN-BGP]の説明との間に競合またはその他の矛盾がある場合、権威ある文書と見なされます。
Please note that the material in this section only applies when inter-site shared trees are being used.
このセクションの資料は、サイト間共有ツリーが使用されている場合にのみ適用されることに注意してください。
Whenever a PE creates an (C-S,C-G) state as a result of receiving a C-multicast route for (C-S,C-G) from some other PE, and the C-G group is an ASM group, the PE that creates the state MUST originate a Source Active A-D route (see [MVPN-BGP], Section 4.5). The NLRI of the route includes C-S and C-G. By default, the route carries the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN originated by the PE. Using the normal BGP procedures, the
PEが他のPEから（C-S、C-G）のCマルチカストルートを受信した結果として（C-S、C-G）状態を作成するたびに、C-GグループはASMグループである場合、状態を作成するPEはソースアクティブA-Dルート（[MVPN-BGP]、セクション4.5を参照）。ルートのNLRIには、C-SとC-Gが含まれます。デフォルトでは、ルートには、PEが発信するMVPNのI-PMSI A-Dルート内と同じルートターゲットのセットが搭載されています。通常のBGP手順を使用して、
route is propagated to all the PEs of the MVPN. For more details, see Section 13.1 ("Source within a Site - Source Active Advertisement") of [MVPN-BGP].
ルートは、MVPNのすべてのPESに伝播されます。詳細については、[MVPN -BGP]のセクション13.1（「サイト内のソースアクティブ広告」）を参照してください。
When, as a result of receiving a new Source Active A-D route, a PE updates its VRF with the route, the PE MUST check if the newly received route matches any (C-*,C-G) entries. If (a) there is a matching entry, (b) the PE does not have (C-S,C-G) state in its MVPN Tree Information Base (MVPN-TIB) for (C-S,C-G) carried in the route, and (c) the received route is selected as the best (using the BGP route selection procedures), then the PE takes the following action:
新しいソースActive A-Dルートを受信した結果、PEはルートでVRFを更新する場合、PEは新しく受信したルートが（C - *、C-G）エントリと一致するかどうかを確認する必要があります。（a）マッチングエントリがある場合、（b）PEには、ルートで運ばれた（C-S、C-G）のMVPNツリー情報ベース（MVPN-TIB）に（C-S、C-G）状態がありません。受信したルートは、（BGPルートの選択手順を使用して）最高として選択され、PEは次のアクションを実行します。
- If the PE's (C-*,C-G) state has a PMSI as a downstream interface, the PE acts as if all the other PEs had pruned C-S off the (C-*,C-G) tree. That is:
- PEの（c - *、c-g）状態が下流インターフェイスとしてPMSIを持っている場合、PEは他のすべてのPEが（c - *、c-g）ツリーからc-sを剪定したかのように動作します。あれは：
* If the PE receives (C-S,C-G) traffic from a CE, it does not transmit it to other PEs.
* PEがCEから（C-S、C-G）トラフィックを受信した場合、他のPESに送信しません。
* Depending on the PIM state of the PE's PE-CE interfaces, the PE may or may not need to invoke PIM procedures to prune C-S off the (C-*,C-G) tree by sending a PIM Prune(S,G,rpt) to one or more of the CEs. This is determined by ordinary PIM procedures. If this does need to be done, the PE SHOULD delay sending the Prune until it first runs a timer; this helps ensure that the source is not pruned from the shared tree until all PEs have had time to receive the Source Active A-D route.
* PEのPE-CEインターフェイスのPIM状態に応じて、PEは、PIM Prune（S、G、RPT）を送信することにより、PIM手順を（C - *、C-G）ツリーからプルネングするためにPIM手順を呼び出す必要がある場合があります。CESの1つ以上。これは、通常のPIM手順によって決定されます。これを行う必要がある場合、PEは最初にタイマーを実行するまでプルーンの送信を遅らせる必要があります。これにより、すべてのPESがソースアクティブA-Dルートを受信する時間があるまで、ソースが共有ツリーから剪定されないようにするのに役立ちます。
- If the PE's (C-*,C-G) state does not have a PMSI as a downstream interface, the PE sets up its forwarding path to receive (C-S,C-G) traffic from the originator of the selected Source Active A-D route.
- PEの（c - *、c-g）状態にダウンストリームインターフェイスとしてPMSIがない場合、PEは選択したソースActive A-Dルートのオリジネーターから（C-S、C-G）トラフィックを受信する転送パスを設定します。
Whenever a PE deletes the (C-S,C-G) state that was previously created as a result of receiving a C-multicast route for (C-S,C-G) from some other PE, the PE that deletes the state also withdraws the Source Active A-D route (if there is one) that was advertised when the state was created.
PEが以前に作成された（C-S、C-G）状態が削除されるたびに、他のPEから（C-S、C-G）のCマルチキャストルートを受信した結果、状態を削除するPEもソースアクティブA-Dルートを引き出します（ある場合）州が作成されたときに宣伝されました。
In the example topology of Section 9.3.1, this procedure will cause PE2 to generate a Source Active A-D route for (C-S,C-G). When this route is received, PE4 will set up its forwarding state to expect (C-S,C-G) packets from PE2. PE1 will change its forwarding state so that (C-S,C-G) packets that it receives from CE1 are not forwarded to any other PEs. (Note that PE1 may still forward (C-S,C-G) packets received from CE1 to CE2, if CE2 has receivers for C-G and those
セクション9.3.1のトポロジの例では、この手順により、PE2は（C-S、C-G）のソースアクティブA-Dルートを生成します。このルートを受信すると、PE4はPE2から（C-S、C-G）パケットを期待する転送状態を設定します。PE1は転送状態を変更して、CE1から受信する（C-S、C-G）パケットが他のPESに転送されないようにします。（CE2がC-Gおよびそれらの受信機を持っている場合、PE1はCE1からCE2に受信したパケット（C-S、C-G）パケットがまだ転送される場合があることに注意してください。
receivers did not switch from the (C-*,C-G) tree to the (C-S,C-G) tree.) As a result, PE3 and PE4 do not receive duplicate packets of the (C-S,C-G) C-flow.
レシーバーは（c-*、c-g）ツリーから（c-s、c-g）ツリーに切り替えませんでした。）その結果、PE3とPE4は（c-s、c-g）c-flowの重複パケットを受け取りません。
With this procedure in place, there is no need to have any kind of C-multicast route that has the semantics of a PIM Prune(S,G,rpt) message.
この手順を導入すると、PIM Prune（S、G、RPT）メッセージのセマンティクスを持つC-Multicastルートの種類がありません。
It is worth noting that if, as a result of this procedure, a PE sets up its forwarding state to receive (C-S,C-G) traffic from the source tree, the UMH is not necessarily the same as it would be if the PE had joined the source tree as a result of receiving a PIM Join for the same source tree from a directly attached CE.
この手順の結果として、PEがソースツリーから（C-S、C-G）トラフィックを受信するように転送状態を設定する場合、UMHは必ずしもPEが結合した場合と同じではないことに注意してください。直接接続されたCEから同じソースツリーのPIM結合を受信した結果としてのソースツリー。
Note that the mechanism described in Section 7.4.1 can be leveraged to advertise an S-PMSI binding along with the source active messages. This is accomplished by using the same BGP Update message to carry both the NLRI of the S-PMSI A-D route and the NLRI of the Source Active A-D route. (Though an implementation processing the received routes cannot assume that this will always be the case.)
セクション7.4.1で説明されているメカニズムは、ソースアクティブメッセージとともにS-PMSIバインディングを宣伝するために活用できることに注意してください。これは、同じBGPアップデートメッセージを使用して、S-PMSI A-DルートのNLRIとソースアクティブA-DルートのNLRIの両方を運ぶことで実現されます。（実装処理では、受信ルートはこれが常にそうであると想定することはできません。）
In the ASM service model, a node that wants to become a receiver for a particular multicast group G first joins a shared tree, rooted at a rendezvous point. When the receiver detects traffic from a particular source, it has the option of joining a source tree, rooted at that source. If it does so, it has to prune that source from the shared tree, to ensure that it receives packets from that source on only one tree.
ASMサービスモデルでは、特定のマルチキャストグループGのレシーバーになりたいノードは、最初にランデブーポイントに根付いた共有ツリーに結合します。受信機が特定のソースからトラフィックを検出すると、そのソースに根付いたソースツリーを結合するオプションがあります。そうする場合は、共有ツリーからそのソースを剪定して、1つのツリーのみでそのソースからパケットを受け取るようにする必要があります。
Maintaining the shared tree can require considerable state, as it is necessary not only to know who the upstream and downstream nodes are, but to know which sources have been pruned off which branches of the share tree.
共有ツリーを維持するには、上流と下流のノードが誰であるかを知る必要があるだけでなく、どのソースがシェアツリーの分岐が剪定されたかを知る必要があるため、かなりの状態を必要とする場合があります。
The BGP-based signaling procedures defined in this document and in [MVPN-BGP] eliminate the need for PEs to distribute to each other any state having to do with which sources have been pruned off a shared C-tree. Those procedures do still allow multicast data traffic to travel on a shared C-tree, but they do not allow a situation in which some CEs receive (S,G) traffic on a shared tree and some on a source tree. This results in a considerable simplification of the PE-PE procedures with minimal change to the multicast service seen within the VPN. However, shared C-trees are still supported across the VPN backbone. That is, (C-*,C-G) state is distributed PE-PE, but (C-*,C-G,rpt) state is not.
このドキュメントおよび[MVPN-BGP]で定義されたBGPベースのシグナル伝達手順は、PESが共有Cトゥリーから剪定された状態を互いに分配する必要性を排除します。これらの手順では、マルチキャストデータトラフィックが共有Cツリーで移動できるようになりますが、一部のCEが共有ツリーのトラフィックを受け取っている状況とソースツリーの一部の状況を許可していません。これにより、VPN内で見られるマルチキャストサービスを最小限に抑えることで、PE-PE手順が大幅に簡素化されます。ただし、共有CツリーはVPNバックボーン全体で依然としてサポートされています。つまり、（c-*、c-g）状態はPE-PEで分布していますが、（c-*、c-g、rpt）状態はそうではありません。
In this section, we specify a number of optional procedures that go further and that completely eliminate the support for shared C-trees across the VPN backbone. In these procedures, the PEs keep track of the active sources for each C-G. As soon as a CE tries to join the (*,G) tree, the PEs instead join the (S,G) trees for all the active sources. Thus, all distribution of (C-*,C-G) state is eliminated. These procedures are optional because they require some additional support on the part of the VPN customer and because they are not always appropriate. (For example, a VPN customer may have his own policy of always using shared trees for certain multicast groups.) There are several different options, described in the following sub-sections.
このセクションでは、さらに進むいくつかのオプションの手順を指定し、VPNバックボーン全体で共有Cトリーのサポートを完全に排除します。これらの手順では、PESは各C-Gのアクティブソースを追跡します。CEが（*、g）ツリーに参加しようとするとすぐに、PESはすべてのアクティブソースの（s、g）ツリーに参加します。したがって、（c - *、c-g）状態のすべての分布は排除されます。これらの手順は、VPN顧客の側面に追加のサポートが必要であり、常に適切ではないため、追加のサポートが必要なため、オプションです。（たとえば、VPNの顧客は、特定のマルチキャストグループに常に共有ツリーを使用するという独自のポリシーを持っている場合があります。）以下のサブセクションで説明されているいくつかの異なるオプションがあります。
[MVPN-REQ] describes C-RP engineering as an issue when PIM-SM (or BIDIR-PIM) is used in Any-Source Multicast (ASM) mode [RFC4607] on the VPN customer site. To quote from [MVPN-REQ]:
[MVPN-REQ]は、VPNカスタマーサイトの任意のソースマルチキャスト（ASM）モード[RFC4607]でPIM-SM（またはBidir-PIM）が使用される場合の問題として、C-RPエンジニアリングを問題として説明しています。[mvpn-req]から引用するには：
In the case of PIM-SM, when a source starts to emit traffic toward a group (in ASM mode), if sources and receivers are located in VPN sites that are different than that of the RP, then traffic may transiently flow twice through the SP network and the CE-PE link of the RP (from source to RP, and then from RP to receivers). This traffic peak, even short, may not be convenient depending on the traffic and link bandwidth.
PIM-SMの場合、ソースがグループに向かってトラフィックを発し始めたとき（ASMモード）、ソースとレシーバーがRPとは異なるVPNサイトに配置されている場合、トラフィックは一時的に2回流れる場合があります。RPのSPネットワークとCE-PEリンク（ソースからRPまで、次にRPから受信機へ）。このトラフィックピークは、短くても、トラフィックとリンクの帯域幅に応じて便利ではない場合があります。
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue.
したがって、VPNソリューションは、この潜在的な問題を解決または緩和する機能を提供する場合があります。
One of the C-RP deployment models is for the customer to outsource the RP to the provider. In this case, the provider may co-locate the RP on the PE that is connected to the customer site [MVPN-REQ]. This section describes how "anycast-RP" can be used to achieve this. This is described below.
C-RP展開モデルの1つは、顧客がRPをプロバイダーに外部委託することです。この場合、プロバイダーは、顧客サイト[MVPN-REQ]に接続されているPEのRPを共同配置することができます。このセクションでは、これを達成するために「Anycast-RP」を使用する方法について説明します。これを以下に説明します。
For a particular MVPN, at least one or more PEs that have sites in that MVPN, act as an RP for the sites of that MVPN connected to these PEs. Within each MVPN, all of these RPs use the same (anycast) address. All of these RPs use the Anycast RP technique.
特定のMVPNの場合、そのMVPNにサイトを持つ少なくとも1つ以上のPESが、これらのPEに接続されたそのMVPNのサイトのRPとして機能します。各MVPN内で、これらのRPはすべて同じ（Anycast）アドレスを使用します。これらのRPはすべて、Anycast RPテクニックを使用しています。
This mechanism is based on propagating active sources between RPs.
このメカニズムは、RP間のアクティブソースの伝播に基づいています。
The PE that receives a C-Join message for (*,G) does not send the information that it has receiver(s) for G until it receives information about active sources for G from an Upstream PE.
（*、g）のC結合メッセージを受信するPEは、上流のPEからGのアクティブソースに関する情報を受信するまで、Gのレシーバーがあるという情報を送信しません。
On receiving this (described in the next section), the downstream PE will respond with a Join message for (C-S,C-G). Sending this information could be done using any of the procedures described in Section 5. Only the Upstream PE will process this information.
これを受信すると（次のセクションで説明）、下流のPEは（C-S、C-G）の参加メッセージで応答します。この情報の送信は、セクション5で説明されている手順のいずれかを使用して実行できます。上流のPEのみがこの情報を処理します。
When a PE receives a PIM Register message from a site that belongs to a given VPN, PE follows the normal PIM anycast RP procedures. It then advertises the source and group of the multicast data packet carried in the PIM Register message to other PEs in BGP using the following information elements:
PEが特定のVPNに属するサイトからPIMレジスタメッセージを受信すると、PEは通常のPIM Anycast RP手順に従います。次に、次の情報要素を使用して、PIMレジスタメッセージにBGPの他のPESに伝達されたマルチキャストデータパケットのソースとグループを宣伝します。
- Active source address
- アクティブなソースアドレス
- Active group address
- アクティブなグループアドレス
- Route target of the MVPN.
- MVPNのルートターゲット。
This advertisement goes to all the PEs that belong to that MVPN. When a PE receives this advertisement, it checks whether there are any receivers in the sites attached to the PE for the group carried in the source active advertisement. If there are, then it generates an advertisement for (C-S,C-G) as specified in the previous section.
この広告は、そのMVPNに属するすべてのPEに送られます。PEがこの広告を受信すると、Source Active Advertisementに携帯されているグループのPEに接続されたサイトにレシーバーがあるかどうかを確認します。ある場合、前のセクションで指定されているように（C-S、C-G）の広告を生成します。
No additional procedures are required when multicast receivers in customer's site shift from shared tree to source tree.
顧客のサイトのマルチキャストレシーバーが共有ツリーからソースツリーに移行する場合、追加の手順は必要ありません。
Section 10.1 describes the case where each PE is a C-RP. This enables the PEs to know the active multicast sources for each MVPN, and they can then use BGP to distribute this information to each other. As a result, the PEs do not have to join any shared C-trees, and this results in a simplification of the PE operation.
セクション10.1では、各PEがC-RPである場合について説明します。これにより、PEは各MVPNのアクティブなマルチキャストソースを知ることができ、BGPを使用してこの情報を相互に配布できます。その結果、PESは共有Cツリーを結合する必要はありません。これにより、PE操作が簡素化されます。
In another deployment scenario, the PEs are not themselves C-RPs, but use Multicast Source Discovery Protocol (MSDP) [RFC3618] to talk to the C-RPs. In particular, a PE that attaches to a site that contains a C-RP becomes an MSDP peer of that C-RP. That PE then uses BGP to
別の展開シナリオでは、PES自体はC-RPSではなく、マルチキャストソースディスカバリープロトコル（MSDP）[RFC3618]を使用してC-RPSと通信します。特に、C-RPを含むサイトに接続するPEは、そのC-RPのMSDPピアになります。そのPEはBGPを使用します
distribute the information about the active sources to the other PEs. When the PE determines, by MSDP, that a particular source is no longer active, then it withdraws the corresponding BGP Update. Then, the PEs do not have to join any shared C-trees, and they do not have to be C-RPs either.
アクティブソースに関する情報を他のPESに配布します。PEがMSDPによって、特定のソースがもはやアクティブではないと判断すると、対応するBGPアップデートを撤回します。その後、PESは共有Cツリーを結合する必要はなく、C-RPSである必要もありません。
MSDP provides the capability for a Source Active (SA) message to carry an encapsulated data packet. This capability can be used to allow an MSDP speaker to receive the first (or first several) packet(s) of an (S,G) flow, even though the MSDP speaker hasn't yet joined the (S,G) tree. (Presumably, it will join that tree as a result of receiving the SA message that carries the encapsulated data packet.) If this capability is not used, the first several data packets of an (S,G) stream may be lost.
MSDPは、カプセル化されたデータパケットを携帯するソースアクティブ（SA）メッセージの機能を提供します。この機能を使用して、MSDPスピーカーがまだ（s、g）ツリーに結合していない場合でも、MSDPスピーカーが（s、g）フローの最初の（または最初の）パケットを受信できるようにすることができます。（おそらく、カプセル化されたデータパケットを運ぶSAメッセージを受信した結果としてそのツリーに参加します。）この機能が使用されない場合、（s、g）ストリームの最初のいくつかのデータパケットが失われる可能性があります。
A PE that is talking MSDP to an RP may receive such an encapsulated data packet from the RP. The data packet should be decapsulated and transmitted to the other PEs in the MVPN. If the packet belongs to a particular (S,G) flow, and if the PE is a transmitter for some S-PMSI to which (S,G) has already been bound, the decapsulated data packet should be transmitted on that S-PMSI. Otherwise, if an I-PMSI exists for that MVPN, the decapsulated data packet should be transmitted on it. (If a MI-PMSI exists, this would typically be used.) If neither of these conditions hold, the decapsulated data packet is not transmitted to the other PEs in the MVPN. The decision as to whether and how to transmit the decapsulated data packet does not affect the processing of the SA control message itself.
MSDPをRPに伝えているPEは、RPからそのようなカプセル化されたデータパケットを受け取る場合があります。データパケットは脱カプセル化し、MVPNの他のPESに送信する必要があります。パケットが特定の（s、g）フローに属し、PEがすでにバインドされているS-PMSIの送信機である場合、脱カプセル化データパケットはそのS-PMSIに送信する必要があります。それ以外の場合、そのMVPNにI-PMSIが存在する場合、脱カプセル化データパケットを送信する必要があります。（Mi-PMSIが存在する場合、これは通常使用されます。）これらの条件のいずれも保持されない場合、脱カプセル化データパケットはMVPNの他のPESに送信されません。脱カプセル化データパケットを送信するかどうか、どのように送信するかについての決定は、SAコントロールメッセージ自体の処理に影響しません。
Suppose that PE1 transmits a multicast data packet on a PMSI, where that data packet is part of an (S,G) flow, and PE2 receives that packet from that PMSI. According to Section 9, if PE1 is not the PE that PE2 expects to be transmitting (S,G) packets, then PE2 must discard the packet. If an MSDP-encapsulated data packet is transmitted on a PMSI, as specified above, this rule from Section 9 would likely result in the packet being discarded. Therefore, if MSDP-encapsulated data packets being decapsulated and transmitted on a PMSI, we need to modify the rules of Section 9 as follows:
PE1がPMSIにマルチキャストデータパケットを送信し、そのデータパケットが（s、g）フローの一部であり、PE2がそのPMSIからそのパケットを受信すると仮定します。セクション9によれば、PE1がPE2がPE2が送信（S、G）パケットを予想していない場合、PE2はパケットを破棄する必要があります。上記で指定されたように、MSDPカプセル化データパケットがPMSIに送信される場合、セクション9のこのルールはパケットが破棄される可能性があります。したがって、MSDPにカプセル化されたデータパケットが脱カプセル化され、PMSIで送信されている場合、次のようにセクション9のルールを変更する必要があります。
1. If the receiving PE, PE2, has already joined the (S,G) tree, and has chosen PE1 as the Upstream PE for the (S,G) tree, but this packet does not come from PE1, PE2 must discard the packet.
1. 受信PE、PE2がすでに（s、g）ツリーに結合し、（s、g）ツリーの上流PEとしてPE1を選択した場合、このパケットはPE1からのものではなく、PE2はパケットを破棄する必要があります。
2. If the receiving PE, PE2, has not already joined the (S,G) tree, but is a PIM adjacency to a CE that is downstream on the (*,G) tree, the packet should be forwarded to the CE.
2. 受信PE、PE2が（s、g）ツリーにまだ結合していないが、（*、g）ツリーの下流のCEへのPIM隣接性である場合、パケットはCEに転送する必要があります。
In BIDIR-PIM, each multicast group is associated with a Rendezvous Point Address (RPA). The Rendezvous Point Link (RPL) is the link that attaches to the RPA. Usually, it's a LAN where the RPA is in the IP subnet assigned to the LAN. The root node of a BIDIR-PIM tree is a node that has an interface on the RPL.
Bidir-PIMでは、各マルチキャストグループはランデブーポイントアドレス（RPA）に関連付けられています。Rendezvous Pointリンク（RPL）は、RPAに付着するリンクです。通常、RPAがLANに割り当てられたIPサブネットにあるLANです。Bidir-PIMツリーのルートノードは、RPLにインターフェイスがあるノードです。
On any LAN (other than the RPL) that is a link in a BIDIR-PIM tree, there must be a single node that has been chosen to be the DF. (More precisely, for each RPA there is a single node that is the DF for that RPA.) A node that receives traffic from an upstream interface may forward it on a particular downstream interface only if the node is the DF for that downstream interface. A node that receives traffic from a downstream interface may forward it on an upstream interface only if that node is the DF for the downstream interface.
Bidir-PIMツリーのリンクであるLAN（RPL以外）には、DFになるように選択された単一のノードが必要です。（より正確には、各RPAには、そのRPAのDFである単一ノードがあります。）アップストリームインターフェイスからトラフィックを受信するノードは、ノードがその下流インターフェイスのDFである場合にのみ、特定のダウンストリームインターフェイスに転送できます。ダウンストリームインターフェイスからトラフィックを受信するノードは、そのノードがダウンストリームインターフェイスのDFである場合にのみ、上流インターフェイスに転送できます。
If, for any period of time, there is a link on which each of two different nodes believes itself to be the DF, data forwarding loops can form. Loops in a bidirectional multicast tree can be very harmful. However, any election procedure will have a convergence period. The BIDIR-PIM DF election procedure is very complicated, because it goes to great pains to ensure that if convergence is not extremely fast, then there is no forwarding at all until convergence has taken place.
いずれかの期間、2つの異なるノードのそれぞれがそれ自体がDFであると信じているリンクがある場合、データ転送ループが形成される可能性があります。双方向のマルチキャストツリーのループは非常に有害です。ただし、選挙手続きには収束期間があります。Bidir-PIM DFの選挙手続きは非常に複雑です。なぜなら、収束が非常に速くない場合、収束が行われるまで転送がまったくないことを保証するのは大きな苦痛になるからです。
Other variants of PIM also have a DF election procedure for LANs. However, as long as the multicast tree is unidirectional, disagreement about who the DF is can result only in duplication of packets, not in loops. Therefore, the time taken to converge on a single DF is of much less concern for unidirectional trees and it is for bidirectional trees.
PIMの他のバリアントには、LANのDF選挙手続きもあります。ただし、マルチキャストツリーが単方向である限り、DFが誰であるかについての意見の相違は、ループではなくパケットの複製のみをもたらす可能性があります。したがって、単一のDFに収束するのにかかる時間は、一方向の木の懸念がはるかに少なく、双方向の木である。
In the MVPN environment, if PIM signaling is used among the PEs, then the standard LAN-based DF election procedure can be used. However, election procedures that are optimized for a LAN may not work as well in the MVPN environment. So, an alternative to DF election would be desirable.
MVPN環境では、PESでPIMシグナル伝達が使用される場合、標準のLANベースのDF選挙手順を使用できます。ただし、LANに対して最適化された選挙手続きは、MVPN環境でも機能しない場合があります。したがって、DF選挙に代わるものが望ましいでしょう。
If BGP signaling is used among the PEs, an alternative to DF election is necessary. One might think that the "Single Forwarder Selection" procedures described in Sections 5 and 9 could be used to choose a single PE "DF" for the backbone (for a given RPA in a given MVPN). However, that is still likely to leave a convergence period of at least several seconds during which loops could form, and there could be a much longer convergence period if there is anything disrupting the smooth flow of BGP Updates. So, a simple procedure like that is not sufficient.
BGPシグナル伝達がPESで使用される場合、DF選挙の代替案が必要です。セクション5および9で説明されている「単一のフォワーダー選択」手順を使用して、バックボーン（特定のMVPNの特定のRPAに対して）の単一PE「DF」を選択できると考えるかもしれません。ただし、それはまだループが形成される可能性がある少なくとも数秒の収束期間を残す可能性が高く、BGP更新のスムーズな流れを混乱させるものがある場合、はるかに長い収束期間がある可能性があります。したがって、そのような簡単な手順では十分ではありません。
The remainder of this section describes two different methods that can be used to support BIDIR-PIM while eliminating the DF election.
このセクションの残りの部分では、DF選挙を排除しながらBidir-PIMをサポートするために使用できる2つの異なる方法について説明します。
On a per-MVPN basis, this method treats the whole service provider(s) infrastructure as a single RPL. We refer to such an RPL as an "MVPN-RPL". This eliminates the need for the PEs to engage in any "DF election" procedure because BIDIR-PIM does not have a DF on the RPL.
MVPNごとに、この方法では、サービスプロバイダー全体を単一のRPLとして扱います。このようなRPLを「MVPN-RPL」と呼びます。これにより、Bidir-PIMにはRPLにDFがないため、PESが「DF選挙」手続きに従事する必要性がなくなります。
However, this method can only be used if the customer is "outsourcing" the RPL/RPA functionality to the SP.
ただし、この方法は、顧客がRPL/RPA機能をSPに「アウトソーシング」している場合にのみ使用できます。
An MVPN-RPL could be realized either via an I-PMSI (this I-PMSI is on a per-MVPN basis and spans all the PEs that have sites of a given MVPN), via a collection of S-PMSIs, or even via a combination of an I-PMSI and one or more S-PMSIs.
MVPN-RPLは、I-PMSI（このI-PMSIはPER-MVPNベースであり、特定のMVPNのサイトを持つすべてのPES）、S-PMSISのコレクションを介して、または介して、I-PMSIと1つ以上のS-PMSISの組み合わせ。
Associated with each MVPN-RPL is an address prefix that is unambiguous within the context of the MVPN associated with the MVPN-RPL.
各MVPN-RPLに関連付けられているのは、MVPN-RPLに関連付けられたMVPNのコンテキスト内で明確なアドレスプレフィックスです。
For a given MVPN, each VRF connected to an MVPN-RPL of that MVPN is configured to advertise to all of its connected CEs the address prefix of the MVPN-RPL.
特定のMVPNの場合、そのMVPNのMVPN-RPLに接続された各VRFは、接続されたすべてのCEにMVPN-RPLのアドレスプレフィックスをすべて広告するように構成されています。
Since, in BIDIR-PIM, there is no Designated Forwarder on an RPL, in the context of MVPN-RPL, there is no need to perform the Designated Forwarder election among the PEs (note it is still necessary to perform the Designated Forwarder election between a PE and its directly attached CEs, but that is done using plain BIDIR-PIM procedures).
Bidir-PIMでは、MVPN-RPLのコンテキストでは、RPLに指定されたフォワーダーがないため、PESの間で指定されたフォワーダー選挙を実行する必要はありません（指定されたフォワーダー選挙を実行する必要があることに注意してください。PEとその直接接続されたCESですが、それは単純なBidir-PIM手順を使用して行われます）。
For a given MVPN, a PE connected to an MVPN-RPL of that MVPN should send multicast data (C-S,C-G) on the MVPN-RPL only if at least one other PE connected to the MVPN-RPL has a downstream multicast state for C-G. In the context of MVPN, this is accomplished by requiring a PE that has a downstream state for a particular C-G of a particular VRF present on the PE to originate a C-multicast route for (C-*,C-G). The RD of this route should be the same as the RD associated with the VRF. The RTs carried by the route should be such as to ensure that the route gets distributed to all the PEs of the MVPN.
特定のMVPNの場合、そのMVPNのMVPN-RPLに接続されたPEは、MVPN-RPLに接続されている少なくとも1つのPEがC-Gの下流マルチキャスト状態を持っている場合にのみ、MVPN-RPLにマルチキャストデータ（C-S、C-G）を送信する必要があります。。MVPNのコンテキストでは、これは、（c - *、c-g）のcマルチキャストルートを発信するために、PEに存在する特定のVRFの特定のC-gに対して下流の状態を持つPEを要求することによって達成されます。このルートのRDは、VRFに関連付けられたRDと同じでなければなりません。ルートで運ばれるRTSは、ルートがMVPNのすべてのPESに分散されるようにするなど、そのようなものでなければなりません。
A PE that receives (C-S,C-G) multicast data from a CE should forward this data on the MVPN-RPL of the MVPN the CE belongs to only if the PE receives at least one C-multicast route for (C-*, C-G). Otherwise, the PE should not forward the data on the RPL/I-PMSI.
CEから（C-S、C-G）マルチキャストデータを受信するPEは、MVPNのMVPN-RPLでこのデータを転送する必要があります。CEは、PEが（C-*、C-G）の少なくとも1つのCマルチキャストルートを受信した場合にのみ属します。。それ以外の場合、PEはRPL/I-PMSI上のデータを転送しないでください。
When a PE receives a multicast packet with (C-S,C-G) on an MVPN-RPL associated with a given MVPN, the PE forwards this packet to every directly connected CE of that MVPN, provided that the CE sends Join (C-*,C-G) to the PE (provided that the PE has the downstream (C-*,C-G) state). The PE does not forward this packet back on the MVPN-RPL. If a PE has no downstream (C-*,C-G) state, the PE does not forward the packet.
特定のMVPNに関連付けられたMVPN-RPLで（C-S、C-G）を使用してPEがマルチキャストパケットを受信すると、CEがJoin（C-*、C-Gが送信された場合、このパケットをそのMVPNの直接接続されたすべてのCEに前方に進めます。）PE（PEが下流（c - *、c-g）状態があることを条件）。PEは、このパケットをMVPN-RPLに転送しません。PEに下流（C - *、C-G）状態がない場合、PEはパケットを転送しません。
This method does not require the use of the MVPN-RPL, and it does not require the customer to outsource the RPA/RPL functionality to the SP.
この方法では、MVPN-RPLの使用は必要ありません。また、顧客がRPA/RPL機能をSPに外注する必要はありません。
Consider a particular C-RPA, call it C-R, in a particular MVPN. Consider the set of PEs that attach to sites that have senders or receivers for a BIDIR-PIM group C-G, where C-R is the RPA for C-G. (As always, we use the "C-" prefix to indicate that we are referring to an address in the VPN's address space rather than in the provider's address space.)
特定のMVPNで特定のC-RPA、それをC-Rと呼ぶことを検討してください。C-RはC-gのRPAであるBidir-PIM Group C-Gの送信者または受信機を持つサイトに接続するPEのセットを考えてください。（いつものように、「C-」プレフィックスを使用して、プロバイダーのアドレススペースではなく、VPNのアドレススペースのアドレスを参照していることを示します。）
Following the procedures of Section 5.1, each PE in the set independently chooses some other PE in the set to be its "Upstream PE" for those BIDIR-PIM groups with RPA C-R. Optionally, they can all choose the "default selection" (described in Section 5.1) to ensure that each PE to choose the same Upstream PE. Note that if a PE has a route to C-R via a VRF interface, then the PE may choose itself as the Upstream PE.
セクション5.1の手順に続いて、セット内の各PEは、RPA C-Rを持つBidir-PIMグループの「上流のPE」になるようにセット内の他のPEを独立して選択します。オプションで、それらはすべて「デフォルト選択」（セクション5.1で説明）を選択して、各PEが同じ上流のPEを選択することを確認できます。PEにVRFインターフェイスを介してC-Rへのルートがある場合、PEは上流のPEとしてそれ自体を選択できることに注意してください。
The set of PEs can now be partitioned into a number of subsets. We'll say that PE1 and PE2 are in the same partition if and only if there is some PE3 such that PE1 and PE2 have each chosen PE3 as the Upstream PE for C-R. Note that each partition has exactly one Upstream PE. So it is possible to identify the partition by identifying its Upstream PE.
PESのセットは、多くのサブセットに分割できるようになりました。PE1とPE2は、C-Rの上流PEとしてPE1とPE2がそれぞれ選択されたPE3を持っている場合にのみ、PE1とPE2が同じパーティションにあると言います。各パーティションにはちょうど1つの上流のPEがあることに注意してください。そのため、上流のPEを識別することにより、パーティションを識別することができます。
Consider packet P, and let PE1 be its ingress PE. PE1 will send the packet on a PMSI so that it reaches the other PEs that need to receive it. This is done by encapsulating the packet and sending it
パケットPを検討し、PE1をその侵入PEとします。PE1は、PMSIにパケットを送信して、受信する必要がある他のPESに到達するようにします。これは、パケットをカプセル化して送信することによって行われます
on a P-tunnel. If the original packet is part of a PIM-BIDIR group (its ingress PE determines this from the packet's destination address C-G), and if the VPN backbone is not the RPL, then the encapsulation MUST carry information that can be used to identify the partition to which the ingress PE belongs.
Pトンネルで。元のパケットがPIM-ビディールグループの一部である場合（その侵入PEはパケットの宛先アドレスC-Gからこれを決定します）、VPNバックボーンがRPLではない場合、カプセル化はパーティションを識別するために使用できる情報を使用する必要があります。イングレスPEが属します。
When PE2 receives a packet from the PMSI, PE2 must determine, by examining the encapsulation, whether the packet's ingress PE belongs to the same partition (relative to the C-RPA of the packet's C-G) to which the PE2 itself belongs. If not, PE2 discards the packet. Otherwise, PE2 performs the normal BIDIR-PIM data packet processing. With this rule in place, harmful loops cannot be introduced by the PEs into the customer's bidirectional tree.
PE2がPMSIからパケットを受信する場合、PE2はカプセル化を調べることにより、PE2自体が属するパケットのパーティション（パケットのC-GのC-RPAと比較して）に属しているかどうかを決定する必要があります。そうでない場合、PE2はパケットを破棄します。それ以外の場合、PE2は通常のBidir-PIMデータパケット処理を実行します。このルールが整っていれば、PESによって顧客の双方向ツリーに有害なループを導入することはできません。
Note that if there is more than one partition, the VPN backbone will not carry a packet from one partition to another. The only way for a packet to get from one partition to another is for it to go up towards the RPA and then down another path to the backbone. If this is not considered desirable, then all PEs should choose the same Upstream PE for a given C-RPA. Then, multiple partitions will only exist during routing transients.
複数のパーティションがある場合、VPNバックボーンは、あるパーティションから別のパーティションにパケットを運ばないことに注意してください。パケットがあるパーティションから別のパーティションに到達する唯一の方法は、RPAに向かって上昇し、バックボーンへの別のパスを下ることです。これが望ましいと見なされない場合、すべてのPESは、特定のC-RPAに対して同じ上流のPEを選択する必要があります。次に、ルーティングトランジェント中にのみ複数のパーティションが存在します。
If a given P-tunnel is to be used to carry packets traveling along a bidirectional C-tree, then, EXCEPT for the case described in Sections 11.1 and 11.2.3, the packets that travel on that P-tunnel MUST carry a PE Distinguisher Label (defined in Section 4), using the encapsulation discussed in Section 12.3.
特定のPトンネルを使用して、双方向Cトゥリーに沿って移動するパケットを運ぶために使用される場合、セクション11.1および11.2.3で説明した場合を除き、そのPトンネルを移動するパケットはPEの違いを運ぶ必要があります。セクション12.3で説明したカプセル化を使用して、ラベル（セクション4で定義）。
When a given PE transmits a given packet of a bidirectional C-group to the P-tunnel, the packet will carry the PE Distinguisher Label corresponding to the partition, for the C-group's C-RPA, that contains the transmitting PE. This is the PE Distinguisher Label that has been bound to the Upstream PE of that partition; it is not necessarily the label that has been bound to the transmitting PE.
特定のPEが双方向Cグループの特定のパケットをPトンネルに送信すると、パケットは、送信PEを含むCグループのC-RPAについて、パーティションに対応するPE違いラベルを運びます。これは、そのパーティションの上流のPEにバインドされているPE違いラベルです。必ずしも送信PEにバインドされているラベルではありません。
Recall that the PE Distinguisher Labels are upstream-assigned labels that are assigned and advertised by the node that is at the root of the P-tunnel. The information about PE Distinguisher Labels is distributed with Intra-AS I-PMSI A-D routes and/or S-PMSI A-D routes by encoding it into the PE Distinguisher Labels attribute carried by these routes.
PE違いのラベルは、Pトンネルのルートにあるノードによって割り当てられ、宣伝されているアップストリーム割り当てのラベルであることを思い出してください。PEの違いラベルに関する情報は、これらのルートによって伝達されるPE distimingerラベル属性属性にエンコードすることにより、IPMSI A-Dルートおよび/またはS-PMSI A-DルートでIntra-AS AS AS AS AS AS AS ASで分散されています。
When a PE receives a packet with a PE label that does not identify the partition of the receiving PE, then the receiving PE discards the packet.
PEが受信PEのパーティションを識別しないPEラベルを含むパケットを受信すると、受信PEはパケットを破棄します。
Note that this procedure does not necessarily require the root of a P-tunnel to assign a PE Distinguisher Label for every PE that belongs to the tunnel. If the root of the P-tunnel is the only PE that can transmit packets to the P-tunnel, then the root needs to assign PE Distinguisher Labels only for those PEs that the root has selected to be the UMHs for the particular C-RPAs known to the root.
この手順では、トンネルに属するすべてのPEにPE違いラベルを割り当てるために、必ずしもPトンネルのルートを必要としないことに注意してください。PトンネルのルートがパケットをPトンネルに送信できる唯一のPEである場合、ルートは、ルートが特定のC-RPAのUMHSに選択したPESに対してのみPE違いラベルを割り当てる必要がありますルートに知られています。
There is one case in which support for BIDIR-PIM C-groups does not require the use of a PE Distinguisher Label. For each C-RPA, suppose a distinct MP2MP LSP is used as the P-tunnel serving that C-RPA's partition. Then, for a given packet, a PE receiving the packet from a P-tunnel can infer the partition from the tunnel. So, PE Distinguisher Labels are not needed in this case.
Bidir-PIM Cグループのサポートでは、PE違いラベルの使用を必要としないケースが1つあります。各C-RPAについて、異なるMP2MP LSPがそのC-RPAのパーティションを提供するPトンネルとして使用されると仮定します。次に、特定のパケットの場合、Pトンネルからパケットを受け取るPEは、トンネルからパーティションを推測できます。したがって、この場合、PE違いのラベルは必要ありません。
The BGP-based auto-discovery procedures will ensure that the PEs in a single MVPN only use tunnels that they can all support, and for a given kind of tunnel, that they only use encapsulations that they can all support.
BGPベースの自動配記手順により、単一のMVPNのPEがすべてサポートできるトンネルのみを使用し、特定の種類のトンネルに対して、すべてサポートできるカプセルのみを使用することが保証されます。
GRE encapsulation can be used for any PMSI that is instantiated by a mesh of unicast P-tunnels, as well as for any PMSI that is instantiated by one or more PIM P-tunnels of any sort.
GREカプセル化は、ユニキャストPターンネルのメッシュによってインスタンス化されたPMSIと、あらゆる種類の1つ以上のPIM P-Tunnelによってインスタンス化されるPMSIに使用できます。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
Packetsは、Egress PESプロバイダーネットワークによってサービスのIngress PEに転送されたトランジットパケットでパケットを受け取りました
+---------------+
| P-IP Header |
+---------------+
| GRE |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The IP Protocol Number field in the P-IP header MUST be set to 47. The Protocol Type field of the GRE header is set to either 0x800 or 0x86dd, depending on whether the C-IP header is IPv4 or IPv6, respectively.
P-IPヘッダーのIPプロトコル番号フィールドは47に設定する必要があります。GREヘッダーのプロトコルタイプフィールドは、C-IPヘッダーがそれぞれIPv4またはIPv6であるかどうかに応じて、0x800または0x86DDに設定されています。
When an encapsulated packet is transmitted by a particular PE, the source IP address in the P-IP header must be the same address that the PE uses to identify itself in the VRF Route Import Extended Communities that it attaches to any of VPN-IP routes eligible for UMH determination that it advertises via BGP (see Section 5.1).
カプセル化されたパケットが特定のPEによって送信される場合、P-IPヘッダーのソースIPアドレスは、VPN-IPルートのいずれかに付着するVRFルートインポートエクステンションコミュニティで自分自身を識別するためにPEが使用するのと同じアドレスでなければなりませんBGPを介して宣伝するというUMHの決定の対象となります（セクション5.1を参照）。
If the PMSI is instantiated by a PIM tree, the destination IP address in the P-IP header is the group P-address associated with that tree. The GRE key field value is omitted.
PMSIがPIMツリーによってインスタンス化されている場合、P-IPヘッダーの宛先IPアドレスは、そのツリーに関連付けられたグループP-Addressです。GREキーフィールド値は省略されています。
If the PMSI is instantiated by unicast P-tunnels, the destination IP address is the address of the destination PE, and the optional GRE key field is used to identify a particular MVPN. In this case, each PE would have to advertise a key field value for each MVPN; each PE would assign the key field value that it expects to receive.
PMSIがUnicast P-Tunnelsによってインスタンス化されている場合、宛先IPアドレスは宛先PEのアドレスであり、オプションのGREキーフィールドは特定のMVPNを識別するために使用されます。この場合、各PEは各MVPNのキーフィールド値を宣伝する必要があります。各PEは、受け取ると予想される重要なフィールド値を割り当てます。
[RFC2784] specifies an optional GRE checksum and [RFC2890] specifies an optional GRE sequence number fields.
[RFC2784]はオプションのGREチェックサムを指定し、[RFC2890]はオプションのGREシーケンス番号フィールドを指定します。
The GRE sequence number field is not needed because the transport layer services for the original application will be provided by the C-IP header.
元のアプリケーションの輸送層サービスはC-IPヘッダーによって提供されるため、GREシーケンス番号フィールドは必要ありません。
The use of the GRE checksum field must follow [RFC2784].
GREチェックサムフィールドの使用は、[RFC2784]に従う必要があります。
To facilitate high speed implementation, this document recommends that the ingress PE routers encapsulate VPN packets without setting the checksum or sequence fields.
高速実装を容易にするために、このドキュメントでは、Ingress PEルーターがチェックサムまたはシーケンスフィールドを設定せずにVPNパケットをカプセル化することを推奨しています。
IP-in-IP [RFC2003] is also a viable option. The following diagram shows the progression of the packet as it enters and leaves the service provider network.
IP-in-IP [RFC2003]も実行可能なオプションです。次の図は、パケットがサービスプロバイダーネットワークに入って出発するときのパケットの進行を示しています。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
Packetsは、Egress PESプロバイダーネットワークによってサービスのIngress PEに転送されたトランジットパケットでパケットを受け取りました
+---------------+
| P-IP Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
When the P-IP header is an IPv4 header, its Protocol Number field is set to either 4 or 41, depending on whether the C-IP header is an IPv4 header or an IPv6 header, respectively.
P-IPヘッダーがIPv4ヘッダーの場合、C-IPヘッダーがそれぞれIPv4ヘッダーかIPv6ヘッダーであるかに応じて、そのプロトコル番号フィールドは4または41に設定されます。
When the P-IP header is an IPv6 header, its Next Header field is set to either 4 or 41, depending on whether the C-IP header is an IPv4 header or an IPv6 header, respectively.
P-IPヘッダーがIPv6ヘッダーの場合、C-IPヘッダーがそれぞれIPv4ヘッダーかIPv6ヘッダーであるかに応じて、次のヘッダーフィールドは4または41に設定されます。
When an encapsulated packet is transmitted by a particular PE, the source IP address in the P-IP header must be the same address that the PE uses to identify itself in the VRF Route Import Extended Communities that it attaches to any of VPN-IP routes eligible for UMH determination that it advertises via BGP (see Section 5.1).
カプセル化されたパケットが特定のPEによって送信される場合、P-IPヘッダーのソースIPアドレスは、VPN-IPルートのいずれかに付着するVRFルートインポートエクステンションコミュニティで自分自身を識別するためにPEが使用するのと同じアドレスでなければなりませんBGPを介して宣伝するというUMHの決定の対象となります（セクション5.1を参照）。
If the PMSI is instantiated as a P2MP MPLS LSP or a MP2MP LSP, MPLS encapsulation is used. Penultimate-hop-popping MUST be disabled for the LSP.
PMSIがP2MP MPLS LSPまたはMP2MP LSPとしてインスタンス化されている場合、MPLSカプセル化が使用されます。LSPでは、最後から2番目のホップポッピングを無効にする必要があります。
If other methods of assigning MPLS labels to multicast distribution trees are in use, these multicast distribution trees may be used as appropriate to instantiate PMSIs, and appropriate additional MPLS encapsulation procedures may be used.
MPLSラベルをマルチキャスト配布ツリーに割り当てる他の方法が使用されている場合、これらのマルチキャスト配布ツリーを適切にPMSIをインスタンス化するために使用でき、適切な追加のMPLSカプセル化手順を使用できます。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
Packetsは、Egress PESプロバイダーネットワークによってサービスのIngress PEに転送されたトランジットパケットでパケットを受け取りました
+---------------+
| P-MPLS Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The encapsulations for transmitting multicast data messages when there are multiple PMSIs per P-tunnel are based on the encapsulation for a single PMSI per P-tunnel, but with an MPLS label used for demultiplexing.
Pトンネルごとに複数のPMSIがある場合にマルチキャストデータメッセージを送信するためのカプセルは、Pトンネルごとに単一のPMSIのカプセル化に基づいていますが、Demultiplexingに使用されるMPLSラベルを使用します。
The label is upstream-assigned and distributed via BGP as specified in Section 4. The label must enable the receiver to select the proper VRF and may enable the receiver to select a particular multicast routing entry within that VRF.
ラベルは、セクション4で指定されているように、上流で割り当てられ、BGPを介して配布されています。ラベルは、受信者が適切なVRFを選択できるようにする必要があり、受信機がそのVRF内の特定のマルチキャストルーティングエントリを選択できるようにする必要があります。
Rather than the IP-in-GRE encapsulation discussed in Section 12.1.1, we use the MPLS-in-GRE encapsulation. This is specified in [MPLS-IP]. The GRE protocol type MUST be set to 0x8847. (The reason for using the unicast rather than the multicast value is specified in [MPLS-MCAST-ENCAPS]).
セクション12.1.1で説明したIP-in-GREカプセル化ではなく、MPLS-in-GREのカプセル化を使用します。これは[MPLS-IP]で指定されています。GREプロトコルタイプは0x8847に設定する必要があります。（マルチキャスト値ではなくユニキャストを使用する理由は、[MPLS-MCAST-ENCAPS]で指定されています）。
Rather than the IP-in-IP encapsulation discussed in Section 12.1.2, we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP]. The IP protocol number field MUST be set to the value identifying the payload as an MPLS unicast packet. (There is no "MPLS multicast packet" protocol number.)
セクション12.1.2で説明したIP-in-IPカプセル化ではなく、MPLS-in-IPカプセル化を使用します。これは[MPLS-IP]で指定されています。IPプロトコル番号フィールドは、MPLSユニキャストパケットとしてペイロードを識別する値に設定する必要があります。（「MPLSマルチキャストパケット」プロトコル番号はありません。）
As discussed in Section 9, if a multicast data packet is traveling on a unidirectional C-tree, it is highly desirable for the PE that receives the packet from a PMSI to be able to determine the identity of the PE that transmitted the data packet onto the PMSI. The encapsulations of the previous sections all provide this information, except in one case. If a PMSI is being instantiated by an MP2MP LSP, then the encapsulations discussed so far do not allow one to determine the identity of the PE that transmitted the packet onto the PMSI.
セクション9で説明したように、マルチキャストデータパケットが単方向のCツリーで移動している場合、PMSIからパケットを受け取るPEがデータパケットを送信したPEのアイデンティティを決定できるようにすることが非常に望ましいです。PMSI。前のセクションのカプセルはすべて、1つのケースを除き、この情報を提供します。PMSIがMP2MP LSPによってインスタンス化されている場合、これまでに議論されたカプセルでは、パケットをPMSIに送信したPEのアイデンティティを決定することはできません。
Therefore, when a packet traveling on a unidirectional C-tree is traveling on a MP2MP LSP P-tunnel, it MUST carry, as its second label, a label that has been bound to the packet's ingress PE. This label is an upstream-assigned label that the LSP's root node has bound to the ingress PE and has distributed via the PE Distinguisher
したがって、単方向のC-Treeを走行するパケットがMP2MP LSP Pトンネルを走行している場合、パケットの侵入PEにバインドされたラベルを2番目のラベルとして運ぶ必要があります。このラベルは、LSPのルートノードが侵入PEにバインドされ、PE違いを介して分布しているアップストリーム割り当てのラベルです。
Labels attribute of a PMSI A-D route (see Section 4). This label will appear immediately beneath the labels that are discussed in Sections 12.1.3 and 12.2.
PMSI A-Dルートのラベル属性（セクション4を参照）。このラベルは、セクション12.1.3および12.2で説明されているラベルの下にすぐに表示されます。
A full specification of the procedures for advertising and for using the PE Distinguisher Labels attribute in this case is outside the scope of this document.
この場合、広告およびPE distiutiuserラベル属性を使用するための手順の完全な仕様は、このドキュメントの範囲外です。
As was discussed in Section 11, when a packet belongs to a PIM-BIDIR multicast group, the set of PEs of that packet's VPN can be partitioned into a number of subsets, where exactly one PE in each partition is the Upstream PE for that partition. When such packets are transmitted on a PMSI, unless the procedures of Section 11.2.3 are being used, it is necessary for the packet to carry information identifying a particular partition. This is done by having the packet carry the PE Distinguisher Label corresponding to the Upstream PE of one partition. For a particular P-tunnel, this label will have been advertised by the node that is the root of that P-tunnel. (A full specification of the procedures for advertising PE Distinguisher Labels is out of the scope of this document.)
セクション11で説明したように、パケットがPIM-BIDIRマルチキャストグループに属している場合、そのパケットのVPNのPESのセットは多くのサブセットに分割できます。各パーティションの1つのPEがそのパーティションの上流のPEです。。このようなパケットがPMSIに送信される場合、セクション11.2.3の手順が使用されていない限り、パケットが特定のパーティションを識別する情報を運ぶ必要があります。これは、1つのパーティションの上流のPEに対応するPE distinguisherラベルをパケットに持ち運ぶことによって行われます。特定のPトンネルの場合、このラベルは、そのPトンネルのルートであるノードによって宣伝されます。（Advertising PE distiutisuriutherラベルの手順の完全な仕様は、このドキュメントの範囲外です。）
This label needs to be used whenever a packet belongs to a PIM-BIDIR C-group, no matter what encapsulation is used by the P-tunnel. Hence, the encapsulations of Section 12.2 MUST be used. If the P-tunnel contains only one PMSI, the PE label replaces the label discussed in Section 12.2. If the P-tunnel contains multiple PMSIs, the PE label follows the label discussed in Section 12.2.
このラベルは、P-Tunnelでどのカプセル化が使用されていても、パケットがPIMビディールCグループに属している場合はいつでも使用する必要があります。したがって、セクション12.2のカプセルを使用する必要があります。Pトンネルに1つのPMSIのみが含まれている場合、PEラベルはセクション12.2で説明したラベルを置き換えます。Pトンネルに複数のPMSIが含まれている場合、PEラベルはセクション12.2で説明されているラベルに従います。
In general, PE Distinguisher Labels can be carried if the encapsulation is MPLS, MPLS-in-IP, or MPLS-in-GRE. However, procedures for advertising and using PE Distinguisher Labels when the encapsulation is LDP-based MP2P MPLS is outside the scope of this specification.
一般に、カプセル化がMPLS、MPLS-in-IP、またはMPLS-in-GREである場合、PEの違いラベルを運ぶことができます。ただし、カプセル化がLDPベースのMP2P MPLSである場合、広告およびPE違いラベルを使用する手順は、この仕様の範囲外です。
These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.
これらは、MPLS-in-IPおよびMPLS-in-GRE-in-GREのカプセルにも適用されます。
It is the responsibility of the originator of a C-packet to ensure that the packet is small enough to reach all of its destinations, even when it is encapsulated within IP or GRE.
IPまたはGRE内でカプセル化されている場合でも、パケットがすべての目的地に到達するのに十分なほど小さいことを保証することは、Cパケットの創始者の責任です。
When a packet is encapsulated in IP or GRE, the router that does the encapsulation MUST set the DF bit in the outer header. This ensures that the decapsulating router will not need to reassemble the encapsulating packets before performing decapsulation.
IPまたはGREでパケットがカプセル化されている場合、カプセル化を行うルーターは、外部ヘッダーにDFビットを設定する必要があります。これにより、脱カプセンティングルーターが脱カプセル化を実行する前にカプセル化パケットを再組み立てる必要がないことが保証されます。
In some cases, the encapsulating router may know that a particular C-packet is too large to reach its destinations. Procedures by which it may know this are outside the scope of the current document. However, if this is known, then:
場合によっては、カプセル化するルーターは、特定のCパケットが大きすぎて目的地に到達できないことを知っている場合があります。これが現在のドキュメントの範囲外であることを知っている手順。ただし、これがわかっている場合は、
- If the DF bit is set in the IP header of a C-packet that is known to be too large, the router will discard the C-packet as being "too large" and follow normal IP procedures (which may require the return of an ICMP message to the source).
- DFビットが大きすぎることが知られているCパケットのIPヘッダーに設定されている場合、ルーターはCパケットを「大きすぎる」と廃棄し、通常のIPプロシージャに従うことができます（これには、ソースへのICMPメッセージ）。
- If the DF bit is not set in the IP header of a C-packet that is known to be too large, the router MAY fragment the packet before encapsulating it and then encapsulate each fragment separately. Alternatively, the router MAY discard the packet.
- DFビットが大きすぎることが知られているCパケットのIPヘッダーに設定されていない場合、ルーターはパケットをカプセル化する前にパケットをフラグメントし、各フラグメントを個別にカプセル化する場合があります。または、ルーターがパケットを破棄する場合があります。
If the router discards a packet as too large, it should maintain Operations, Administration, and Maintenance (OAM) information related to this behavior, allowing the operator to properly troubleshoot the issue.
ルーターがパケットを大きすぎると破棄する場合、この動作に関連する操作、管理、およびメンテナンス（OAM）情報を維持し、オペレーターが問題を適切にトラブルシューティングできるようにする必要があります。
Note that if the entire path of the P-tunnel does not support an MTU that is large enough to carry the a particular encapsulated C-packet, and if the encapsulating router does not do fragmentation, then the customer will not receive the expected connectivity.
Pトンネルのパス全体が、特定のカプセル化されたCパケットを運ぶのに十分な大きさのMTUをサポートしていない場合、およびカプセル化ルーターが断片化を行わない場合、顧客は予想される接続を受け取らないことに注意してください。
The ingress PE should not copy the TTL field from the payload IP header received from a CE router to the delivery IP or MPLS header. The setting of the TTL of the delivery header is determined by the local policy of the ingress PE router.
Ingress PEは、CEルーターから受信したペイロードIPヘッダーからTTLフィールドを配信IPまたはMPLSヘッダーにコピーしないでください。配信ヘッダーのTTLの設定は、イングレスPEルーターのローカルポリシーによって決定されます。
If the SP is providing Internet multicast, distinct from its VPN multicast services, and using PIM based P-multicast trees, it must ensure that the group P-addresses that it used in support of MVPN services are distinct from any of the group addresses of the Internet multicasts it supports. This is best done by using administratively scoped addresses [ADMIN-ADDR].
SPがVPNマルチキャストサービスとは異なるインターネットマルチキャストを提供し、PIMベースのP-Multicastツリーを使用している場合、MVPNサービスのサポートで使用したグループPアドレスが、のグループアドレスのいずれかとは異なることを確認する必要があります。サポートするインターネットマルチキャスト。これは、管理上スコープアドレス[Admin-ADDR]を使用して行うのが最適です。
The group C-addresses need not be distinct from either the group P-addresses or the Internet multicast addresses.
グループCアドレスは、グループPアドレスまたはインターネットマルチキャストアドレスのいずれかとは異なる必要はありません。
The setting of the DS (Differentiated Services) field in the delivery IP header should follow the guidelines outlined in [RFC2983]. Setting the Traffic Class field [RFC5462] in the delivery MPLS header should follow the guidelines in [RFC3270]. An SP may also choose to deploy any of additional Differentiated Services mechanisms that the PE routers support for the encapsulation in use. Note that the type of encapsulation determines the set of Differentiated Services mechanisms that may be deployed.
配信IPヘッダーのDS（差別化されたサービス）フィールドの設定は、[RFC2983]で概説されているガイドラインに従う必要があります。配信MPLSヘッダーにトラフィッククラスフィールド[RFC5462]の設定[RFC3270]のガイドラインに従う必要があります。SPは、PEルーターが使用中のカプセル化をサポートする追加の差別化されたサービスメカニズムのいずれかを展開することもできます。カプセル化のタイプは、展開される可能性のある差別化されたサービスメカニズムのセットを決定することに注意してください。
This document describes an extension to the procedures of [RFC4364], and hence shares the security considerations described in [RFC4364] and [RFC4365].
このドキュメントは、[RFC4364]の手順の拡張を説明しているため、[RFC4364]および[RFC4365]に記載されているセキュリティ上の考慮事項を共有しています。
When GRE encapsulation is used, the security considerations of [MPLS-IP] are also relevant. Additionally, the security considerations of [RFC4797] are relevant as it discusses implications on packet spoofing in the context of BGP/MPLS IP VPNs.
GREカプセル化を使用すると、[MPLS-IP]のセキュリティに関する考慮事項も関連しています。さらに、[RFC4797]のセキュリティ上の考慮事項は、BGP/MPLS IP VPNSのコンテキストでのパケットスプーフィングへの影響を議論するため、関連しています。
The security considerations of [MPLS-HDR] apply when MPLS encapsulation is used.
[MPLS-HDR]のセキュリティ上の考慮事項は、MPLSカプセル化が使用される場合に適用されます。
This document makes use of a number of control protocols: PIM [PIM-SM], BGP [MVPN-BGP], mLDP [MLDP], and RSVP-TE [RSVP-P2MP]. Security considerations relevant to each protocol are discussed in the respective protocol specifications.
このドキュメントでは、PIM [PIM-SM]、BGP [MVPN-BGP]、MLDP [MLDP]、およびRSVP-TE [RSVP-P2MP]の多くの制御プロトコルを使用しています。各プロトコルに関連するセキュリティ上の考慮事項については、それぞれのプロトコル仕様で説明します。
If one uses the UDP-based protocol for switching to S-PMSI (as specified in Section 7.4.2), then an S-PMSI Join message (i.e., a UDP packet with destination port 3232 and destination address ALL-PIM-ROUTERS) that is not received over a PMSI (e.g., one received directly from a CE router) is an illegal packet and MUST be dropped.
S-PMSIに切り替えるためにUDPベースのプロトコルを使用している場合（セクション7.4.2で指定）、S-PMSI結合メッセージ（つまり、宛先ポート3232と宛先アドレスのAll-PIM-Routerを備えたUDPパケット）それはPMSI（たとえば、CEルーターから直接受け取ったもの）で受け取られていません。違法なパケットであり、削除する必要があります。
The various procedures for P-tunnel construction have security issues that are specific to the way that the P-tunnels are used in this document. When P-tunnels are constructed via such techniques as PIM, mLDP, or RSVP-TE, each P or PE router receiving a control message MUST ensure that the control message comes from another P or PE router, not from a CE router. (Interpreting an mLDP or PIM or RSVP-TE control message from a CE router as referring to a P-tunnel would be a bug.)
Pトンネル構造のさまざまな手順には、このドキュメントでPタンネルが使用される方法に固有のセキュリティ問題があります。PIM、MLDP、またはRSVP-TEなどの手法を介してP-Tunnelが構築される場合、コントロールメッセージを受信する各PまたはPEルーターがコントロールメッセージがCEルーターではなく別のPまたはPEルーターから来ることを確認する必要があります。（CEルーターからのMLDPまたはPIMまたはRSVP-TEコントロールメッセージをPトンネルを参照すると解釈することはバグです。）
A PE MUST NOT accept BGP routes of the MCAST-VPN address family from a CE.
PEは、CEからMCAST-VPNアドレスファミリーのBGPルートを受け入れてはなりません。
If BGP is used as a CE-PE routing protocol, then when a PE receives an IP route from a CE, if this route carries the VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPN-IP route. Routes that a PE advertises to a CE MUST NOT carry the VRF Route Import Extended Community.
BGPがCE-PEルーティングプロトコルとして使用される場合、PEがCEからIPルートを受信する場合、このルートがVRFルートインポートエクステンションコミュニティを運ぶ場合、PEはVPNに変える前にこのコミュニティをルートから削除する必要があります。-IPルート。PEがCEに宣伝するルートは、VRFルートインポートエクステンションコミュニティを運ぶべきではありません。
An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE control message that attempts to extend a P-tunnel from one SP's domain into another SP's domain. This is perfectly valid if there is an agreement between the SPs to jointly provide an MVPN service. In the absence of such an agreement, however, this could be an illegitimate attempt to intercept data packets. By default, an ASBR MUST NOT allow P-tunnels to extend beyond AS boundaries. However, it MUST be possible to configure an ASBR to allow this on a specified set of interfaces.
ASBRは、1つのSPのドメインから、MLDP、PIM、またはRSVP-TEコントロールメッセージを受け取る場合があります。これは、あるSPのドメインから別のSPのドメインにPトンネルを拡張しようとします。これは、MVPNサービスを共同で提供するというSPSの間に合意がある場合、完全に有効です。ただし、そのような合意がない場合、これはデータパケットを傍受するための非合法的な試みである可能性があります。デフォルトでは、ASBRはP-Tunnelが境界として拡張することを許可してはなりません。ただし、指定されたインターフェイスでこれを許可するようにASBRを構成することが可能である必要があります。
Many of the procedures in this document cause the SP network to create and maintain an amount of state that is proportional to customer multicast activity. If the amount of customer multicast activity exceeds expectations, this can potentially cause P and PE routers to maintain an unexpectedly large amount of state, which may cause control and/or data plane overload. To protect against this situation, an implementation should provide ways for the SP to bound the amount of state it devotes to the handling of customer multicast activity.
このドキュメントの手順の多くは、SPネットワークが顧客のマルチキャスト活動に比例する状態の量を作成および維持するようになります。顧客のマルチキャストアクティビティの量が期待を超える場合、これによりPおよびPEルーターが予期せず大量の状態を維持する可能性があり、制御および/またはデータプレーンの過負荷を引き起こす可能性があります。この状況から保護するために、実装は、SPが顧客マルチキャストアクティビティの処理に捧げる状態の量を拘束する方法を提供する必要があります。
In particular, an implementation SHOULD provide mechanisms that allow an SP to place limitations on the following:
特に、実装は、SPが以下に制限を置くことを可能にするメカニズムを提供する必要があります。
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF
- VRFあたりの（c-*、c-g）および/または（c-s、c-g）状態の総数
- total number of P-tunnels per VRF used for S-PMSIs
- S-PMSISに使用されるVRFあたりのPタンネルの総数
- total number of P-tunnels traversing a given P router
- 特定のPルーターを通過するPタンネルの総数
A PE implementation MAY also provide mechanisms that allow an SP to limit the rate of change of various MVPN-related states on PEs, as well as the rate at which MVPN-related control messages may be received by a PE from the CEs and/or sent from the PE to other PEs.
PE実装は、SPがPES上のさまざまなMVPN関連状態の変化率を制限できるメカニズムと、CESおよび/またはPEによってMVPN関連の制御メッセージが受信されるレートを提供する場合があります。PEから他のPEに送信されます。
An implementation that provides the procedures specified in Sections 10.1 or 10.2 MUST provide the capability to impose an upper bound on the number of Source Active A-D routes generated and on how frequently they may be originated. This MUST be provided on a per-PE, per-MVPN granularity.
セクション10.1または10.2で指定された手順を提供する実装は、生成されたソースアクティブA-Dルートの数とそれらがどれだけ頻繁に発生するかに上限を課す機能を提供する必要があります。これは、PE、PER-MVPN粒度で提供する必要があります。
Lack of the mechanisms that allow an SP to limit the rate of change of various MVPN-related states on PEs, as well as the rate at which MVPN-related control messages may be received by a PE from the CEs and/or sent from the PE to other PEs may result in the control plane overload on the PE, which in turn would adversely impact all the customers connected to that PE, as well as to other PEs.
SPがPES上のさまざまなMVPN関連状態の変化率を制限できるメカニズムの欠如、およびMVPN関連の制御メッセージがCEからPEによって受信される可能性があるレートおよび/または他のPEへのPEは、PEでコントロールプレーンの過負荷を引き起こす可能性があり、その結果、そのPEに接続されているすべての顧客や他のPEに悪影響を及ぼします。
See also the Security Considerations section of [MVPN-BGP].
[MVPN-BGP]のセキュリティに関する考慮事項セクションも参照してください。
Section 7.4.2 defines the "S-PMSI Join message", which is carried in a UDP datagram whose port number is 3232. This port number had already been assigned by IANA to "MDT port". The reference has been updated to this document.
セクション7.4.2は、「S-PMSI結合メッセージ」を定義します。これは、ポート番号が3232のUDPデータグラムに掲載されています。このポート番号は、すでにIANAによって「MDTポート」に割り当てられていました。参照はこのドキュメントに更新されました。
IANA has created a registry for the "S-PMSI Join message Type Field". Assignments are to be made according to the policy "IETF Review" as defined in [RFC5226]. The value 1 has been registered with a reference to this document. The description reads "PIM IPv4 S-PMSI (unaggregated)".
IANAは、「S-PMSI結合メッセージタイプフィールド」のレジストリを作成しました。[RFC5226]で定義されているように、ポリシー「IETFレビュー」に従って割り当てが行われます。値1は、このドキュメントへの参照とともに登録されています。説明には「pim ipv4 s-pmsi（凝集していない）」と書かれています。
[PIM-ATTRIB] establishes a registry for "PIM Join attribute Types". IANA has assigned the value 1 to the "MVPN Join Attribute" with a reference to this document.
[PIM-ATTRIB]は、「PIM結合属性タイプ」のレジストリを確立します。IANAは、このドキュメントへの参照を使用して、値1を「MVPN参加属性」に割り当てました。
IANA has assigned SAFI 129 to "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" with a reference to this document and [MVPN-BGP].
IANAは、このドキュメントと[MVPN-BGP]を参照して、SAFI 129を「BGP/MPLS IP仮想プライベートネットワーク（VPNS）のマルチキャスト」に割り当てました。
Significant contributions were made Arjen Boers, Toerless Eckert, Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Giuliano, Shankar Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony Speakman, Dan Tappan.
Arjen Boers、Toerless Eckert、Adrian Farrel、Luyuan Fang、Dino Farinacci、Lenny Giuliano、Shankar Karuna、Anil Lohiya、Tom Pusateri、Ted Qian、Robert Raszuk、Tony Speakman、Dan Tappan。
[MLDP] 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, November 2011.
[MLDP] Wijnands、IJ。、ed。、Minei、I.、ed。、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチパスのラベル分布プロトコル拡張」、RFC 6388、2011年11月。
[MPLS-HDR] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-HDR] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLS Label Stack Encoding」、RFC 3032、2001年1月。
[MPLS-IP] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-IP] Worster、T.、Rekhter、Y。、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[MPLS-MCAST-ENCAPS] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[MPLS-MCAST-ENCAPS] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル」、RFC 5332、2008年8月。
[MPLS-UPSTREAM-LABEL] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[Mpls-Upstream-Label] Aggarwal、R.、Rekhter、Y.、およびE. Rosen、「Mpls Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[MVPN-BGP] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS/BGP IP VPNSのマルチキャストのBGPエンコーディングと手順」、RFC 6514、2012年2月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[OSPF-MT] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「Multi-Topology（MT）Routing in OSPF」、RFC 4915、2007年6月。
[PIM-ATTRIB] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[Pim-Attrib] Boers、A.、Wijnands、I。、およびE. Rosen、「プロトコル独立マルチキャスト（PIM）結合属性形式」、RFC 5384、2008年11月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、 "Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）、RFC 4601、2006年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想プライベートネットワーク（VPN）IPv6 VPNの拡張」、RFC 4659、2006年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
[RSVP-OOB] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.
[RSVP-OOB] Ali、Z.、Swallow、G。、およびR. Aggarwal、「RSVP-TEラベルの切り替えパスの非ペニルなホップポップ動作とバンド外マッピング」、RFC 6511、2012年2月。
[RSVP-P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RSVP-P2MP] Aggarwal、R.、Ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTE用トラフィックエンジニアリング（RSVP-TE）ラベルスイッチ付きパス（LSP） "、RFC 4875、2007年5月。
[ADMIN-ADDR] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Admin-Addr] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[BIDIR-PIM] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[Bidir-Pim] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[BSR] Bhaskar、N.、Gall、A.、Lingard、J。、およびS. Venaas、「ブートストラップルーター（BSR）プロトコル独立マルチキャスト（PIM）のメカニズム」、RFC 5059、2008年1月。
[MVPN-REQ] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[MVPN-Req] Morin、T.、ed。、「レイヤー3プロバイダーである仮想プライベートネットワーク（PPVPNS）のマルチキャストの要件」、RFC 4834、2007年4月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「Key and Sequence Number GREへの拡張」、RFC 2890、2000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B.、ed。、およびD. Meyer、ed。、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365] Rosen、E。、「BGP/MPLS IP仮想ネットワーク（VPNS）の適用性ステートメント」、RFC 4365、2006年2月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC 4797, January 2007.
[RFC4797] Rekhter、Y.、Bonica、R。、およびE. Rosen、「プロバイダーエッジのエッジエッジ（PE-PE）ジェネリックルーティングカプセル化（GRE）またはBGP/MPLS IP仮想ネットワークでのIPの使用」、RFC4797、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Contributing Authors
貢献している著者
Sarveshwar Bandi Motorola Vanenburg IT park, Madhapur, Hyderabad, India EMail: sarvesh@motorola.com
Sarveshwar Bandi Motorola Vanenburg IT Park、Madhapur、Hyderabad、India Email：sarvesh@motorola.com
Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ycai@cisco.com
Yiqun Cai Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134メール：Ycai@cisco.com
Thomas Morin France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@francetelecom.com
トーマスモリンフランステレコムR＆D 2、アベニューピエールマルツィン22307ラニオンセデックスフランスメール：thomas.morin@francetelecom.com
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：yakov@juniper.net
IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ice@cisco.com
IJSBRAND Wijnands Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134メール：ice@cisco.com
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
Seisho Yasukawa NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585、日本電話：81 422 59 4769メール：Yasukawa.seisho@lab.ntt.co.jp
Editors' Addresses
編集者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
Eric C. Rosen Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA、01719メール：erosen@cisco.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：raggarwa_1@yahoo.com