[要約] RFC 7524は、異なるエリア間でのポイントツーマルチポイント（P2MP）セグメント化されたラベルスイッチパス（LSP）に関する仕様です。このRFCの目的は、異なるエリア間でのP2MPトラフィックの効率的な転送を実現するためのソリューションを提供することです。
Internet Engineering Task Force (IETF) Y. Rekhter
Request for Comments: 7524 E. Rosen
Category: Standards Track Juniper Networks
ISSN: 2070-1721 R. Aggarwal
Arktan
T. Morin
I. Grosclaude
Orange
N. Leymann
Deutsche Telekom AG
S. Saad
AT&T
May 2015
Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
エリア間ポイントツーマルチポイント（P2MP）セグメント化ラベルスイッチドパス（LSP）
Abstract
概要
This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.
このドキュメントでは、このようなLSPをエリア内セグメントに分割し、BGPをエリア間ルーティングおよびラベル配布プロトコル（LDP）として使用することにより、エリア間ポイントツーマルチポイント（P2MP）セグメントサービスラベルスイッチドパス（LSP）を構築する手順について説明します。各IGPエリア内で、エリア内セグメントは、P2MP LSP階層を使用してエリア内P2MP LSPで伝送されるか、入力レプリケーションを使用してインスタンス化されます。エリア内P2MP LSPは、P2MP RSVP-TEまたはP2MPマルチポイントLDP（mLDP）を使用してシグナリングできます。 IGPエリア内で入力レプリケーションが使用されている場合、IGPエリアでは（マルチポイントツーポイント）LDP LSPまたは（ポイントツーポイント）RSVP-TE LSPが使用されます。このようなエリア間サービスLSPを使用するアプリケーション/サービスは、BGPマルチキャストVPN、仮想プライベートLANサービス（VPLS）マルチキャスト、またはMPLS上のグローバルテーブルマルチキャストの場合があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7524.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7524で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. General Assumptions and Terminology .............................6
4. Inter-Area P2MP Segmented Next-Hop Extended Community ...........7
5. Discovering P2MP FEC of Inter-Area P2MP Service LSP .............8
5.1. BGP MVPN ...................................................8
5.1.1. Routes Originated by PE or ASBR .....................9
5.1.2. Routes Re-advertised by PE or ASBR ..................9
5.1.3. Inter-Area Routes ...................................9
5.2. LDP VPLS with BGP Auto-discovery or BGP VPLS ..............10
5.2.1. Routes Originated by PE or ASBR ....................10
5.2.2. Routes Re-advertised by PE or ASBR .................11
5.2.3. Inter-Area Routes ..................................11
5.3. Global Table Multicast over MPLS ..........................12
6. Egress PE/ASBR Signaling Procedures ............................13
6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) ......13
6.1.1. Upstream Node for MVPN or VPLS .....................13
6.1.2. Upstream Node for Global Table Multicast ...........14
6.2. Originating a Leaf A-D Route ..............................15
6.2.1. Leaf A-D Route for MVPN and VPLS ...................15
6.2.2. Leaf A-D Route for Global Table Multicast ..........15
6.2.3. Constructing the Rest of the Leaf A-D Route ........17
6.3. PIM-SM in ASM Mode for Global Table Multicast .............18
6.3.1. Option 1 ...........................................18
6.3.1.1. Originating Source Active A-D Routes ......18
6.3.1.2. Receiving BGP Source Active A-D
Route by PE ...............................19
6.3.1.3. Handling (S,G,rpt) State ..................19
6.3.2. Option 2 ...........................................19
6.3.2.1. Originating Source Active A-D Routes ......19
6.3.2.2. Receiving BGP Source Active A-D Route .....20
6.3.2.3. Pruning Sources Off the Shared Tree .......20
6.3.2.4. More on Handling (S,G,rpt) State ..........21
7. Egress ABR Procedures ..........................................21
7.1. Handling Leaf A-D Route on Egress ABR .....................21
7.2. P2MP LSP as the Intra-Area LSP in the Egress Area .........23
7.2.1. Received Leaf A-D Route Is for MVPN or VPLS ........23
7.2.2. Received Leaf A-D Route Is for Global Table
Multicast ..........................................24
7.2.2.1. Global Table Multicast and S-PMSI
A-D Routes ................................24
7.2.2.2. Global Table Multicast and
Wildcard S-PMSI A-D Routes ................25
7.2.3. Global Table Multicast and the Expected
Upstream Node ......................................25
7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP ............26
7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........26
7.3. Ingress Replication in the Egress Area ....................26
8. Ingress ABR Procedures .........................................27
8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area .......27
8.2. Ingress Replication in the Backbone Area ..................27
9. Ingress PE/ASBR Procedures .....................................28
9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area ........28
9.2. Ingress Replication in the Ingress Area ...................29
10. Common Tunnel Type in the Ingress and Egress Areas ............29
11. Placement of Ingress and Egress PEs ...........................30
12. MVPN with Virtual Hub-and-Spoke ...............................31
13. Data Plane ....................................................31
13.1. Data Plane Procedures on ABRs ............................31
13.2. Data Plane Procedures on Egress PEs ......................32
13.3. Data Plane Procedures on Ingress PEs .....................33
13.4. Data Plane Procedures on Transit Routers .................33
14. Support for Inter-Area Transport LSPs .........................33
14.1. "Transport Tunnel" Tunnel Type ...........................33
14.2. Discovering Leaves of the Inter-Area P2MP Service LSP ....34
14.3. Discovering P2MP FEC of P2MP Transport LSP ...............34
14.4. Egress PE Procedures for P2MP Transport LSP ..............35
14.5. ABRs and Ingress PE Procedures for P2MP Transport LSP ....35
14.6. Discussion ...............................................36
15. IANA Considerations ...........................................38
16. Security Considerations .......................................38
17. References ....................................................39
17.1. Normative References .....................................39
17.2. Informative References ...................................41
Acknowledgements ..................................................41
Authors' Addresses ................................................42
This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, potentially using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE [RFC4875] or P2MP mLDP [RFC6388]. If ingress replication is used in an IGP area, then (multipoint-to-point) LDP LSPs [RFC5036] or (point-to-point) RSVP-TE LSPs [RFC3209] may be used within the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table multicast over MPLS.
このドキュメントでは、そのようなLSPをエリア内セグメントに分割し、エリア間ルーティングおよびラベル配布プロトコルとしてBGPを使用することにより、エリア間ポイントツーマルチポイント（P2MP）セグメント化サービスLSPを構築する手順について説明します。各IGPエリア内で、エリア内セグメントは、エリア内P2MP LSPを介して、場合によってはP2MP LSP階層を使用して、または入力レプリケーションを使用してインスタンス化されます。エリア内P2MP LSPは、P2MP RSVP-TE [RFC4875]またはP2MP mLDP [RFC6388]を使用してシグナリングできます。 IGPエリアで入力レプリケーションが使用される場合、IGPエリア内で（マルチポイントツーポイント）LDP LSP [RFC5036]または（ポイントツーポイント）RSVP-TE LSP [RFC3209]を使用できます。このようなエリア間サービスLSPを使用するアプリケーション/サービスは、BGPマルチキャストVPN（BGP MVPN）、VPLSマルチキャスト、またはMPLSを介したグローバルテーブルマルチキャストです。
The primary use case of such segmented P2MP service LSPs is when the Provider Edge (PE) routers are in different areas but in the same Autonomous System (AS) and thousands or more of PEs require P2MP connectivity. For instance, this may be the case when MPLS is pushed further to the metro edge and the metros are in different IGP areas. This may also be the case when a service provider's network comprises multiple IGP areas in a single AS, with a large number of PEs. Seamless MPLS is the industry term to address this case [SEAMLESS-MPLS]. Thus, one of the applicabilities of this document is that it describes the multicast procedures for seamless MPLS.
このようなセグメント化されたP2MPサービスLSPの主な使用例は、プロバイダーエッジ（PE）ルーターが異なるエリアにあるが同じ自律システム（AS）にあり、数千以上のPEがP2MP接続を必要とする場合です。たとえば、MPLSがメトロエッジにさらにプッシュされ、メトロが異なるIGPエリアにある場合などです。これは、サービスプロバイダーのネットワークが単一のASに複数のIGPエリアを含み、PEが多数ある場合にも当てはまります。シームレスMPLSは、このケースに対処するための業界用語です[SEAMLESS-MPLS]。したがって、このドキュメントの適用性の1つは、シームレスなMPLSのマルチキャスト手順について説明していることです。
It is to be noted that [RFC6514] and [RFC7117] already specify procedures for building segmented inter-AS P2MP service LSPs. This document complements those procedures, as it extends the segmented P2MP LSP model such that it is applicable to inter-area P2MP service LSPs as well. In fact, an inter-AS deployment could use inter-AS segmented P2MP LSPs as specified in [RFC6514] and [RFC7117] where each intra-AS segment is constructed using inter-area segmented P2MP LSPs, as specified in this document.
[RFC6514]および[RFC7117]は、セグメント化されたAS間P2MPサービスLSPを構築するための手順をすでに指定していることに注意してください。このドキュメントは、セグメント化されたP2MP LSPモデルを拡張し、エリア間P2MPサービスLSPにも適用できるようにするため、これらの手順を補足します。実際、AS間展開では、[RFC6514]と[RFC7117]で指定されているAS間セグメント化P2MP LSPを使用できます。AS内セグメントはそれぞれ、このドキュメントで指定されているエリア間セグメント化P2MP LSPを使用して構築されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The reader is assumed to be familiar with MVPN procedures and terminology [RFC6513] [RFC6514] and VPLS procedures and terminology [RFC7117].
読者は、MVPNの手順と用語[RFC6513] [RFC6514]およびVPLSの手順と用語[RFC7117]に精通していることを前提としています。
This document allows Area Border Routers (ABRs), acting as Route Reflectors, to follow the procedures specified in [SEAMLESS-MPLS] when handling the BGP Next Hop of the routes to the PEs. Specifically, when reflecting such routes from the non-backbone areas into the backbone area, the ABRs MUST set the BGP Next Hop to their own loopback addresses (next-hop-self), while when reflecting such routes from the backbone area into the non-backbone areas, the ABRs SHOULD NOT change the BGP Next Hop addresses (next-hop-unchanged).
このドキュメントでは、ルートリフレクターとして機能するエリアボーダールーター（ABR）が、PEへのルートのBGPネクストホップを処理するときに、[SEAMLESS-MPLS]で指定された手順に従うことができます。具体的には、このようなルートを非バックボーンエリアからバックボーンエリアに反映する場合、ABRはBGPネクストホップを独自のループバックアドレス（next-hop-self）に設定する必要があります。バックボーンエリアでは、ABRはBGPネクストホップアドレスを変更しないでください（next-hop-unchanged）。
While this document allows ABRs to follow the procedures specified in [SEAMLESS-MPLS], procedures specified in this document are applicable even when ABRs do not follow the procedures specified in [SEAMLESS-MPLS].
このドキュメントでは、ABRが[SEAMLESS-MPLS]で指定された手順に従うことを許可していますが、このドキュメントで指定された手順は、ABRが[SEAMLESS-MPLS]で指定された手順に従っていない場合でも適用できます。
This document specifies a particular way of supporting the global table multicast service. Although the document refers to this approach simply as "global table multicast", it does not mean to imply that there are no other ways to support global table multicast.
このドキュメントでは、グローバルテーブルマルチキャストサービスをサポートする特定の方法を指定します。このドキュメントでは、このアプローチを単に「グローバルテーブルマルチキャスト」と呼んでいますが、グローバルテーブルマルチキャストをサポートする他の方法がないことを意味するものではありません。
An alternative way to support global table multicast is to use the procedures for MVPN that are specified in [RFC6514] and in this document. That alternative is discussed in more detail in [GTM]. However, that alternative is not further considered in the current document.
グローバルテーブルマルチキャストをサポートする別の方法は、[RFC6514]およびこのドキュメントで指定されているMVPNの手順を使用することです。その代替案は、[GTM]でより詳細に説明されています。ただし、その代替案は、現在のドキュメントではさらに検討されていません。
This document assumes that, in the context of global table multicast, ABRs do not carry routes to the destinations external to their own AS. Furthermore, in the context of global table multicast, this document assumes that an Autonomous System Border Router (ASBR), when re-advertising into Internal BGP (IBGP) routes received from an external speaker (received via External BGP (EBGP)), may not change the BGP Next Hop to self.
このドキュメントでは、グローバルテーブルマルチキャストのコンテキストでは、ABRは自身のASの外部の宛先へのルートを伝送しないことを前提としています。さらに、グローバルテーブルマルチキャストのコンテキストでは、このドキュメントでは、自律システムボーダールーター（ASBR）が、外部スピーカーから受信した内部BGP（IBGP）ルートに再アドバタイズするとき（外部BGP（EBGP）経由で受信）、 BGP Next Hopをselfに変更しないでください。
Within an AS, a P2MP service LSP is partitioned into three segments: ingress area segment, backbone area segment, and egress area segment. Within each area, a segment is carried over an intra-area P2MP LSP or instantiated using ingress replication.
AS内では、P2MPサービスLSPは、入力エリアセグメント、バックボーンエリアセグメント、および出力エリアセグメントの3つのセグメントに分割されます。各エリア内で、セグメントはエリア内P2MP LSPを介して伝送されるか、入力レプリケーションを使用してインスタンス化されます。
When intra-area P2MP LSPs are used to instantiate the intra-area segments, there could be either 1:1 or n:1 mapping between intra-area segments of the inter-area P2MP service LSP and a given intra-area P2MP LSP. The latter is realized using P2MP LSP hierarchy with upstream-assigned labels [RFC5331]. For simplicity of presentation, we assume that P2MP LSP hierarchy is used even with 1:1 mapping; in which case, an Implicit NULL is used as the upstream-assigned label.
エリア内P2MP LSPを使用してエリア内セグメントをインスタンス化する場合、エリア間P2MPサービスLSPのエリア内セグメントと特定のエリア内P2MP LSPの間に1：1またはn：1のマッピングが存在する可能性があります。後者は、上流に割り当てられたラベルを備えたP2MP LSP階層を使用して実現されます[RFC5331]。表示を簡単にするために、1対1のマッピングでもP2MP LSP階層が使用されると想定しています。その場合、上流に割り当てられたラベルとして暗黙のNULLが使用されます。
When intra-area segments of the inter-area P2MP service LSP are instantiated using ingress replication, multiple such segments may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be achieved using downstream-assigned labels alone.
エリア間P2MPサービスLSPのエリア内セグメントが入力レプリケーションを使用してインスタンス化される場合、そのような複数のセグメントが同じP2P RSVP-TEまたはMP2P LDP LSPで伝送される場合があります。これは、ダウンストリームに割り当てられたラベルのみを使用して実現できます。
The ingress area segment of a P2MP service LSP is rooted at a PE (or at an ASBR in the case where the P2MP service LSP spans multiple ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the same area as the root PE.
P2MPサービスLSPの入力エリアセグメントは、PE（またはP2MPサービスLSPが複数のASにまたがる場合はASBR）をルートとします。このセグメントのリーフは、ルートPEと同じエリアにある他のPE / ASBRおよびABRです。
The backbone area segment is rooted at either an ABR that is connected to the ingress area (ingress ABR), an ASBR if the ASBR is present in the backbone area, or a PE if the PE is present in the backbone area. The backbone area segment has its leaf ABRs that are connected to the egress area(s) or PEs in the backbone area, or ASBRs in the backbone area.
バックボーンエリアセグメントは、入力エリア（入力ABR）に接続されているABR、ASBRがバックボーンエリアに存在する場合はASBR、またはPEがバックボーンエリアに存在する場合はPEをルートとします。バックボーンエリアセグメントには、バックボーンエリアの出力エリアまたはPE、またはバックボーンエリアのASBRに接続されているリーフABRがあります。
The egress area segment is rooted at an ABR in the egress area (egress ABR), and has its leaf PEs and ASBR in that egress area (the latter covers the case where the P2MP service LSP spans multiple ASes). For a given P2MP service LSP, note that there may be more than one backbone segment, each rooted at its own ingress ABR, and more than one egress area segment, each rooted at its own egress ABR.
出力エリアセグメントは、出力エリア（出力ABR）のABRをルートとし、その出力エリアにリーフPEとASBRがあります（後者は、P2MPサービスLSPが複数のASにまたがる場合をカバーします）。特定のP2MPサービスLSPについて、それぞれが独自の入力ABRをルートとする複数のバックボーンセグメントと、それぞれが独自の出力ABRをルートとする複数の出力エリアセグメントがある場合があることに注意してください。
This document uses the term "A-D routes" for "auto-discovery routes".
このドキュメントでは、「自動検出ルート」に「A-Dルート」という用語を使用しています。
An implementation that supports this document MUST implement the procedures described in the following sections to support inter-area P2MP segmented service LSPs.
このドキュメントをサポートする実装は、エリア間P2MPセグメント化サービスLSPをサポートするために、次のセクションで説明する手順を実装する必要があります。
This document defines a new Transitive IPv4-Address-Specific Extended Community Sub-Type: "Inter-Area P2MP Next-Hop". This document also defines a new BGP Transitive IPv6-Address-Specific Extended Community Sub-Type: "Inter-Area P2MP Next-Hop".
このドキュメントでは、新しい推移的なIPv4-Address-Specific Extended Community Sub-Type： "Inter-Area P2MP Next-Hop"を定義しています。このドキュメントでは、新しいBGP Transitive IPv6-Address-Specific Extended Community Sub-Type： "Inter-Area P2MP Next-Hop"も定義しています。
A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented Next-Hop Extended Community as follows:
PE、ABR、またはASBRは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを次のように構築します。
- The Global Administrator field MUST be set to an IP address of the PE, ABR, or ASBR that originates or advertises the route carrying the P2MP Next-Hop Extended Community. For example this address may be the loopback address or the PE, ABR, or ASBR that advertises the route.
- グローバル管理者フィールドは、P2MPネクストホップ拡張コミュニティを伝送するルートを発信またはアドバタイズするPE、ABR、またはASBRのIPアドレスに設定する必要があります。たとえば、このアドレスは、ループバックアドレス、またはルートをアドバタイズするPE、ABR、またはASBRです。
- The Local Administrator field MUST be set to 0.
- Local Administratorフィールドは0に設定する必要があります。
If the Global Administrator field is an IPv4 address, the IPv4-Address-Specific Extended Community is used; if the Global Administrator field is an IPv6 address, the IPv6-Address-Specific Extended Community is used.
Global AdministratorフィールドがIPv4アドレスの場合、IPv4-Address-Specific Extended Communityが使用されます。 Global AdministratorフィールドがIPv6アドレスの場合、IPv6-Address-Specific Extended Communityが使用されます。
The detailed usage of these Extended Communities is described in the following sections.
これらの拡張コミュニティの詳細な使用方法については、次のセクションで説明します。
Each inter-area P2MP service LSP has associated with it P2MP Forwarding Equivalence Class (FEC). The egress PEs need to learn this P2MP FEC in order to initiate the creation of the egress area segment of the P2MP inter-area service LSP.
各エリア間P2MPサービスLSPには、P2MP転送等価クラス（FEC）が関連付けられています。出力PEは、P2MPエリア間サービスLSPの出力エリアセグメントの作成を開始するために、このP2MP FECを学習する必要があります。
The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs either by configuration or based on the application-specific procedures (e.g., MVPN-specific procedures or VPLS-specific procedures).
エリア間P2MP LSPのP2MP FECは、構成によって、またはアプリケーション固有の手順（MVPN固有の手順やVPLS固有の手順など）に基づいて、出力PEによって学習されます。
Egress PEs and/or ASBRs discover the P2MP FEC of the service LSPs used by BGP MVPN using the Inclusive Provider Multicast Service Interface (I-PMSI) or Selective PMSI (S-PMSI) A-D routes that are originated by the ingress PEs or ASBRs following the procedures of [RFC6514], along with modifications as described in this document. The Network Layer Reachability Information (NLRI) of such routes encodes the P2MP FEC.
出力PEまたはASBR、あるいはその両方は、BPE MVPNが使用するサービスLSPのP2MP FECを、次の入力PEまたはASBRが発信する包括的プロバイダーマルチキャストサービスインターフェイス（I-PMSI）または選択的PMSI（S-PMSI）ADルートを使用して検出します。 [RFC6514]の手順、およびこのドキュメントで説明されている変更。このようなルートのネットワーク層到達可能性情報（NLRI）は、P2MP FECをエンコードします。
The procedures in this document require that at least one ABR in a given IGP area act as a Route Reflector for MVPN A-D routes. Such a Router Reflector is responsible for re-advertising MVPN A-D routes across area boundaries. When re-advertising these routes across area boundaries, this Route Reflector MUST follow the procedures in this document. Note that such a Route Reflector may also re-advertise MVPN A-D routes within the same area; in which case, it follows the plain BGP Route Reflector procedures [RFC4456].
このドキュメントの手順では、特定のIGPエリア内の少なくとも1つのABRがMVPN A-Dルートのルートリフレクターとして機能する必要があります。このようなルーターリフレクターは、エリア境界を越えてMVPN A-Dルートを再アドバタイズする責任があります。エリアの境界を越えてこれらのルートを再アドバタイズする場合、このルートリフレクターはこのドキュメントの手順に従う必要があります。このようなルートリフレクタは、同じエリア内のMVPN A-Dルートも再アドバタイズする可能性があることに注意してください。その場合、それはプレーンなBGPルートリフレクター手順[RFC4456]に従います。
The "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute carried in the MVPN A-D routes, when originated by the ingress PEs or ASBRs, except for the case where (a) as a matter of policy (provisioned on the ingress PEs or ASBRs) there is no aggregation of ingress area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the ingress area. Before any Leaf A-D route is advertised by a PE or ABR in the same area, as described in the following sections, an I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel attribute, if the Tunnel Identifier has already been assigned, or with a special Tunnel Type of "No tunnel information present" otherwise.
「Leaf Information Required」フラグは、MVPN ADルートで伝送されるPMSIトンネル属性に設定する必要があります。ただし、（a）ポリシーの問題として（入力PEでプロビジョニングされる）場合を除き、またはASBR）サービスLSPの入力エリアセグメントの集約はありません。（b）mLDPは、入力エリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。次のセクションで説明するように、リーフADルートが同じエリア内のPEまたはABRによってアドバタイズされる前に、I-PMSI / S-PMSI ADルートは、明示的なトンネルタイプとPMSIトンネル属性のトンネル識別子のいずれかでアドバタイズされます。 、トンネル識別子がすでに割り当てられている場合、または特別なトンネルタイプ「トンネル情報なし」が割り当てられている場合。
When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (a) as a matter of policy (provisioned on the ingress ABR) there is no aggregation of backbone area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the backbone area. Likewise, when the I-PMSI/S-PMSI A-D routes are re-advertised by an egress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (a) as a matter of policy (provisioned on the egress ABR) there is no aggregation of egress area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the egress area.
I-PMSI / S-PMSI ADルートが入力ABRによって再アドバタイズされるとき、「Leaf Information Required」フラグは、ルートに存在するPMSIトンネル属性に設定する必要があります。ただし、（a）がポリシーの問題（入力ABRでプロビジョニング）には、サービスLSPのバックボーンエリアセグメントの集約はありません。（b）mLDPは、バックボーンエリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。同様に、I-PMSI / S-PMSI ADルートが出口ABRによって再アドバタイズされる場合、（Leaf Information Required）フラグは、（a）の場合を除いて、ルートに存在するPMSI Tunnel属性に設定する必要がありますポリシーの問題として（出力ABRでプロビジョニングされます）、サービスLSPの出力エリアセグメントの集約はありません。（b）mLDPは、出力エリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。
Note that the procedures in the above paragraph apply when intra-area segments are realized by either intra-area P2MP LSPs or by ingress replication.
上記の段落の手順は、エリア内セグメントがエリア内P2MP LSPまたは入力レプリケーションによって実現される場合に適用されることに注意してください。
When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or propagated to signal inter-area P2MP service LSPs, to indicate that these LSPs should be segmented using the procedures specified in this document, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community MUST be included in the I-PMSI/S-PMSI A-D route by the PE that originates such a route, or an ASBR that re-advertises such a route into its own AS. The Global Administrator field in this Extended Community MUST be set to the advertising PE or ASBR's IP address. This Extended Community MUST also be included by ABRs as they re-advertise such routes. An ABR MUST set the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community to its own IP address. Presence of this Extended Community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to follow the procedures in this document when these procedures differ from those in [RFC6514].
BGP MVPN I-PMSIまたはS-PMSI ADルートがエリア間P2MPサービスLSPを通知するためにアドバタイズまたは伝搬される場合、これらのLSPがこのドキュメントで指定された手順を使用してセグメント化される必要があることを示すため、これらのルートはエリア間P2MPを伝送する必要がありますセグメント化されたネクストホップ拡張コミュニティ。この拡張コミュニティは、そのようなルートを発信するPE、またはそのようなルートを自身のASに再アドバタイズするASBRによって、I-PMSI / S-PMSI A-Dルートに含まれている必要があります。この拡張コミュニティのグローバル管理者フィールドは、アドバタイジングPEまたはASBRのIPアドレスに設定する必要があります。この拡張コミュニティは、そのようなルートを再アドバタイズするときに、ABRにも含める必要があります。 ABRは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティのグローバル管理者フィールドを独自のIPアドレスに設定する必要があります。 I-PMSI / S-PMSI A-Dルートにこの拡張コミュニティが存在することは、これらの手順が[RFC6514]の手順と異なる場合、このドキュメントの手順に従う必要があることをABRおよびPE / ASBRに示します。
If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route that carries the Inter-Area P2MP Segmented Next-Hop Extended Community, then before re-advertising this route to an EBGP peer, the ASBR SHOULD remove this Extended Community from the route.
ASBRがIBGPピアから、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送するI-PMSIまたはS-PMSI ADルートを受信した場合、このルートをEBGPピアに再アドバタイズする前に、ASBRはこの拡張を削除する必要があります（SHOULD）ルートからのコミュニティ。
Suppose an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and this route carries the Inter-Area P2MP Segmented Next-Hop Extended Community. If the inter-area P2MP service LSP signaled by this route should not be segmented, then before re-advertising this route to its IBGP peers, the ASBR MUST remove this Extended Community from the route.
ASBRがEBGPピアからI-PMSI / S-PMSI A-Dルートを受信し、このルートがエリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送するとします。このルートによってシグナリングされたエリア間P2MPサービスLSPをセグメント化しない場合は、このルートをIBGPピアに再アドバタイズする前に、ASBRはこの拡張コミュニティをルートから削除する必要があります。
To avoid requiring ABRs to participate in the propagation of C-multicast routes, this document requires that ABRs MUST NOT modify the BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency, this document requires that ABRs MUST NOT modify the BGP Next Hop when re-advertising either Intra-AS or Inter-AS I-PMSI/S-PMSI A-D routes. The egress PEs may advertise the C-multicast routes to RRs that are different than the ABRs. However, ABRs can still be configured to be the Route Reflectors for C-multicast routes; in which case, they will participate in the propagation of C-multicast routes.
ABRがCマルチキャストルートの伝播に参加する必要がないように、このドキュメントでは、ABRがInter-AS I-PMSI A-Dルートを再アドバタイズするときにBGPネクストホップを変更してはならないことを要求しています。一貫性を保つために、このドキュメントでは、ABRがIntra-ASまたはInter-AS I-PMSI / S-PMSI A-Dルートを再アドバタイズするときにBGPネクストホップを変更してはならないことを要求しています。出力PEは、ABRとは異なるRRにCマルチキャストルートをアドバタイズする場合があります。ただし、ABRは引き続きCマルチキャストルートのルートリフレクターになるように構成できます。その場合、それらはCマルチキャストルートの伝播に参加します。
Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, using the VPLS A-D routes that are originated by the ingress PEs [RFC4761] [RFC6074] or VPLS S-PMSI A-D routes that are originated by the ingress PEs [RFC7117]. The NLRI of such routes encodes the P2MP FEC.
出力PEは、入力PEから発信されたVPLS A-Dルート[RFC4761] [RFC6074]または入力PE [RFC7117]から発信されたVPLS S-PMSI A-Dルートを使用して、VPLSによって使用されるサービスLSPのP2MP FECを検出します。このようなルートのNLRIは、P2MP FECをエンコードします。
The "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute carried in the VPLS A-D routes or VPLS S-PMSI A-D routes, when originated by the ingress PEs or ASBRs, except for the case where (a) as a matter of policy (provisioned on the ingress PEs or ASBRs) there is no aggregation of ingress area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the ingress area. Before any Leaf A-D route is advertised by a PE or ABR in the same area, as described in the following sections, a VPLS/S-PMSI A-D route is advertised either with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel attribute, if the Tunnel Identifier has already been assigned, or with a special Tunnel Type of "No tunnel information present" otherwise.
「Leaf Information Required」フラグは、VPLS ADルートまたはVPLS S-PMSI ADルートで運ばれるPMSIトンネル属性に設定する必要があります。ただし、（a）の問題として、ポリシー（入力PEまたはASBRでプロビジョニング）には、サービスLSPの入力エリアセグメントの集約はありません。（b）mLDPは、入力エリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。次のセクションで説明するように、リーフADルートが同じエリア内のPEまたはABRによってアドバタイズされる前に、VPLS / S-PMSI ADルートは、明示的なトンネルタイプとPMSIトンネル属性のトンネル識別子のいずれかでアドバタイズされます。トンネル識別子はすでに割り当てられているか、それ以外の場合は「トンネル情報がありません」という特別なトンネルタイプが割り当てられています。
When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (a) as a matter of policy (provisioned on the ingress ABR) there is no aggregation of backbone area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the backbone area. Likewise, when the VPLS/S-PMSI A-D routes are re-advertised by an egress ABR, the "Leaf Information Required" flag MUST be set in the PMSI Tunnel attribute present in the routes, except for the case where (a) as a matter of policy (provisioned on the egress ABR) there is no aggregation of egress area segments of the service LSPs and (b) mLDP is used as the protocol to establish intra-area transport LSPs in the egress area.
VPLS / S-PMSI ADルートが入力ABRによって再アドバタイズされるとき、「Leaf Information Required」フラグがルートに存在するPMSI Tunnel属性に設定されている必要があります。ただし、（a）がポリシー（入力ABRでプロビジョニングされます）サービスLSPのバックボーンエリアセグメントの集約はありません。（b）mLDPは、バックボーンエリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。同様に、VPLS / S-PMSI ADルートが出口ABRによって再アドバタイズされる場合、「Leaf Information Required」フラグは、ルートに存在するPMSIトンネル属性に設定する必要があります。ただし、（a）がポリシーの問題（出力ABRでプロビジョニング）には、サービスLSPの出力エリアセグメントの集約はありません。（b）mLDPは、出力エリアでエリア内トランスポートLSPを確立するためのプロトコルとして使用されます。
When VPLS A-D routes or S-PMSI A-D routes are advertised or propagated to signal inter-area P2MP service LSPs, to indicate that these LSPs should be segmented using the procedures specified in this document, these routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community MUST be included in the A-D route by the PE or ASBR that originates such a route, and the Global Administrator field MUST be set to the advertising PE or ASBR's IP address. This Extended Community MUST also be included by ABRs as they re-advertise such routes. An ABR MUST set the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community to its own IP address. Presence of this Extended Community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to follow the procedures in this document when these procedures differ from those in [RFC7117].
VPLS ADルートまたはS-PMSI ADルートがエリア間P2MPサービスLSPを通知するためにアドバタイズまたは伝播される場合、これらのLSPがこのドキュメントで指定された手順を使用してセグメント化される必要があることを示すため、これらのルートはエリア間P2MPセグメント化された次を運ぶ必要があります-ホップ拡張コミュニティ。この拡張コミュニティは、そのようなルートを発信するPEまたはASBRによってA-Dルートに含まれている必要があり、グローバル管理者フィールドは、アドバタイジングPEまたはASBRのIPアドレスに設定されている必要があります。この拡張コミュニティは、そのようなルートを再アドバタイズするときに、ABRにも含める必要があります。 ABRは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティのグローバル管理者フィールドを独自のIPアドレスに設定する必要があります。 I-PMSI / S-PMSI A-Dルートにこの拡張コミュニティが存在すると、ABRとPE / ASBRは、これらの手順が[RFC7117]の手順と異なる場合、このドキュメントの手順に従う必要があることを示します。
Note that the procedures in the above paragraph apply when intra-area segments are realized by either intra-area P2MP LSPs or by ingress replication.
上記の段落の手順は、エリア内セグメントがエリア内P2MP LSPまたは入力レプリケーションによって実現される場合に適用されることに注意してください。
The procedures in this document require that at least one ABR in a given area act as a Route Reflector for VPLS A-D routes. Such a Router Reflector is responsible for re-advertising VPLS A-D routes across areas boundaries. When re-advertising these routes across areas boundaries, this Route Reflector MUST follow the procedures in this document. Note that such a Route Reflector may also re-advertise VPLS A-D routes within the same area; in which case, it follows plain BGP Route Reflector procedures [RFC4456].
このドキュメントの手順では、特定のエリアの少なくとも1つのABRがVPLS A-Dルートのルートリフレクターとして機能する必要があります。このようなルーターリフレクターは、エリア境界を越えてVPLS A-Dルートを再アドバタイズする責任があります。エリアの境界を越えてこれらのルートを再アドバタイズする場合、このルートリフレクターはこのドキュメントの手順に従う必要があります。このようなルートリフレクターは、同じエリア内のVPLS A-Dルートも再アドバタイズする場合があることに注意してください。その場合は、プレーンなBGPルートリフレクター手順[RFC4456]に従います。
When re-advertising VPLS A-D routes, a Route Reflector MUST NOT modify the BGP Next Hop of these routes.
VPLS A-Dルートを再アドバタイズするとき、ルートリフレクターはこれらのルートのBGPネクストホップを変更してはなりません（MUST NOT）。
This section describes how the egress PEs discover the P2MP FEC when the application is global table multicast over an MPLS-capable infrastructure. In the rest of the document, we will refer to this application as "global table multicast".
このセクションでは、アプリケーションがMPLS対応インフラストラクチャ上のグローバルテーブルマルチキャストである場合に、出力PEがP2MP FECを検出する方法について説明します。ドキュメントの残りの部分では、このアプリケーションを「グローバルテーブルマルチキャスト」と呼びます。
When Protocol Independent Multicast - Sparse Mode (PIM-SM) is used for non-bidirectional ASM ("Any Source Multicast") group addresses, this document refers to this as "PIM-SM in ASM mode".
プロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）が非双方向ASM（「Any Source Multicast」）グループアドレスに使用される場合、このドキュメントではこれを「ASMモードのPIM-SM」と呼びます。
In the case where global table multicast uses PIM-SM in ASM mode, the following assumes that an inter-area P2MP service LSP could be used to carry traffic either on a shared (*,G) or a source (S,G) tree.
グローバルテーブルマルチキャストがASMモードでPIM-SMを使用する場合、以下では、エリア間P2MPサービスLSPを使用して、共有（*、G）または送信元（S、G）ツリーでトラフィックを伝送できると想定しています。 。
An egress PE learns the (S/*,G) of a multicast stream as a result of receiving IGMP or PIM messages on one of its IP multicast interfaces. This (S/*,G) forms the P2MP FEC of the inter-area P2MP service LSP. For each such P2MP FEC, there MAY exist a distinct inter-area P2MP service LSP, or multiple such FECs MAY be carried over a single P2MP service LSP using a wildcard (*,*) S-PMSI [RFC6625].
出力PEは、IPマルチキャストインターフェイスの1つでIGMPまたはPIMメッセージを受信した結果として、マルチキャストストリームの（S / *、G）を学習します。これは、（S / *、G）エリア間P2MPサービスLSPのP2MP FECを形成します。そのようなP2MP FECごとに、異なるエリア間P2MPサービスLSPが存在してもよいし、複数のそのようなFECがワイルドカード（*、*）S-PMSI [RFC6625]を使用して単一のP2MPサービスLSPで運ばれてもよい（MAY）。
Note that this document does not require the use of (*,G) inter-area P2MP service LSPs when global table multicast uses PIM-SM in ASM mode. In fact, PIM-SM in ASM mode may be supported entirely by using only (S,G) inter-area P2MP service LSPs.
このドキュメントでは、グローバルテーブルマルチキャストがASMモードでPIM-SMを使用する場合、（*、G）エリア間P2MPサービスLSPを使用する必要がないことに注意してください。実際、ASMモードのPIM-SMは、（S、G）エリア間P2MPサービスLSPのみを使用することで完全にサポートできます。
This section describes the egress PE/ASBR procedures for constructing segmented inter-area P2MP LSPs. The procedures in this section apply irrespective of whether the egress PE/ASBR is in a leaf IGP area, the backbone area, or even in the same IGP area as the ingress PE/ASBR.
このセクションでは、セグメント化されたエリア間P2MP LSPを構築するための出力PE / ASBR手順について説明します。このセクションの手順は、出力PE / ASBRがリーフIGPエリア、バックボーンエリア、または入力PE / ASBRと同じIGPエリアにあるかどうかに関係なく適用されます。
An egress PE/ASBR applies procedures specified in this section to MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the Inter-Area P2MP Segmented Next-Hop Extended Community. An egress PE applies procedures specified in this section to VPLS A-D routes or VPLS S-PMSI A-D routes only if these routes carry the Inter-Area P2MP Segmented Next-Hop Extended Community.
出力PE / ASBRは、これらのルートがエリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送する場合にのみ、このセクションで指定された手順をMVPN I-PMSIまたはS-PMSI A-Dルートに適用します。出力PEは、このセクションで指定されている手順をVPLS A-DルートまたはVPLS S-PMSI A-Dルートに適用します。これらのルートがエリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送する場合のみです。
In order to support global table multicast, an egress PE MUST be auto-configured to import routes that carry an AS-specific Route Target Extended Community ([RFC4360]) with the Global Administrator field set to the AS of the PE and the Local Administrator field set to 0.
グローバルテーブルマルチキャストをサポートするには、グローバル管理者フィールドがPEのASとローカル管理者に設定されたAS固有のルートターゲット拡張コミュニティ（[RFC4360]）を伝送するルートをインポートするように、出力PEを自動構成する必要があります。フィールドは0に設定されています。
Once an egress PE/ASBR discovers the P2MP FEC of an inter-area segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to construct the segmented inter-area P2MP service LSP. This propagation uses BGP Leaf A-D routes.
出力PE / ASBRがエリア間セグメント化P2MPサービスLSPのP2MP FECを検出すると、セグメント化されたエリア間P2MPサービスLSPを構築するために、BGPでこのP2MP FECを伝播する必要があります。この伝播は、BGPリーフA-Dルートを使用します。
An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP segmented service LSP as described in Section 5. Once the egress PE/ASBR discovers this P2MP FEC, it MUST determine the upstream node to reach such a FEC. If the egress PE/ASBR and the ingress PE/ASBR are not in the same area, and the egress PE/ASBR is not in the backbone IGP area, then this upstream node would be an egress ABR. If the egress PE/ASBR is in the backbone area and the ingress PE/ASBR is not in the backbone area, then this upstream node would be an ingress ABR. If the egress PE/ASBR is in the same area as the ingress PE/ASBR, then this upstream node would be the ingress PE/ASBR.
出力PE / ASBRは、セクション5で説明されているように、エリア間P2MPセグメント化サービスLSPのP2MP FECを検出します。出力PE / ASBRがこのP2MP FECを検出したら、そのようなFECに到達する上流ノードを決定する必要があります。出力PE / ASBRと入力PE / ASBRが同じエリアになく、出力PE / ASBRがバックボーンIGPエリアにない場合、このアップストリームノードは出力ABRになります。出力PE / ASBRがバックボーンエリアにあり、入力PE / ASBRがバックボーンエリアにない場合、このアップストリームノードは入力ABRになります。出力PE / ASBRが入力PE / ASBRと同じエリアにある場合、このアップストリームノードは入力PE / ASBRになります。
If the application is MVPN or VPLS, then the upstream node's IP address is the IP address determined from the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community. As described in Section 5, this Extended Community MUST be carried in the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area P2MP segmented service LSP is determined.
アプリケーションがMVPNまたはVPLSの場合、上流ノードのIPアドレスは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティのグローバル管理者フィールドから決定されたIPアドレスです。セクション5で説明したように、この拡張コミュニティは、エリア間P2MPセグメント化サービスLSPのP2MP FECが決定されるMVPNまたはVPLS A-Dルートで運ばれる必要があります。
If the application is global table multicast, then the unicast routes to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended Community [RFC6514] where the IP address in the Global Administrator field is set to the IP address of the PE or ASBR advertising the unicast route. The Local Administrator field of this Extended Community MUST be set to 0 (note that this is in contrast to the case of MVPN, where the Local Administrator field carries a non-zero value that identifies a particular VRF on a PE that originates VPN-IP routes). If it is not desirable to advertise the VRF Route Import Extended Community in unicast routes, then unicast routes to multicast sources/RPs MUST be advertised using the multicast Subsequent Address Family Identifier (SAFI), i.e., SAFI 2, and such routes MUST carry the VRF Route Import Extended Community.
アプリケーションがグローバルテーブルマルチキャストの場合、マルチキャストソース/ RPへのユニキャストルートは、「VRFルートインポート」拡張コミュニティ[RFC6514]を伝送する必要があります[RFC6514]。グローバル管理者フィールドのIPアドレスは、PEまたはASBRのIPアドレスに設定されます。ユニキャストルートをアドバタイズします。この拡張コミュニティのローカル管理者フィールドは0に設定する必要があります（これは、VPN-IPを発信するPE上の特定のVRFを識別するゼロ以外の値をローカル管理者フィールドが運ぶMVPNの場合とは対照的であることに注意してください）ルート）。ユニキャストルートでVRFルートインポート拡張コミュニティをアドバタイズすることが望ましくない場合、マルチキャスト送信元/ RPへのユニキャストルートは、マルチキャストサブアドレスファミリID（SAFI）、つまりSAFI 2を使用してアドバタイズする必要があり、そのようなルートは、 VRFルートインポート拡張コミュニティ。
Further, if the application is global table multicast, then the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-Area P2MP Segmented Next-Hop Extended Community. The IP address in the Global Administrator field of this Extended Community MUST be set to the IP address of the PE, ASBR, or ABR advertising the unicast route. The Local Administrator field of this Extended Community MUST be set to 0. If it is not desirable to advertise the Inter-Area P2MP Segmented Next-Hop Extended Community in BGP unicast routes, then the BGP unicast routes to the IP addresses of PEs/ASBRs/ABRs MUST be advertised using the multicast SAFI, i.e., SAFI 2, and such routes MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. The procedures for handling the BGP Next Hop attribute of SAFI 2 routes are the same as those of handling regular unicast routes and MAY follow [SEAMLESS-MPLS].
さらに、アプリケーションがグローバルテーブルマルチキャストの場合、ルートをPE / ASBR / ABRのIPアドレスにアドバタイズするBGPユニキャストルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを運ぶ必要があります。この拡張コミュニティのグローバル管理者フィールドのIPアドレスは、ユニキャストルートをアドバタイズするPE、ASBR、またはABRのIPアドレスに設定する必要があります。この拡張コミュニティのローカル管理者フィールドは0に設定する必要があります。BGPユニキャストルートでエリア間P2MPセグメント化ネクストホップ拡張コミュニティをアドバタイズすることが望ましくない場合、PE / ASBRのIPアドレスへのBGPユニキャストルート/ ABRは、マルチキャストSAFI、つまりSAFI 2を使用してアドバタイズされなければならず（MUST）、そのようなルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを運ぶ必要があります。 SAFI 2ルートのBGPネクストホップ属性を処理する手順は、通常のユニキャストルートを処理する手順と同じで、[SEAMLESS-MPLS]に従う場合があります。
If the application is global table multicast, then in order to determine the upstream node address, the egress PE first determines the ingress PE. In order to determine the ingress PE, the egress PE determines the best route to reach the S/RP. The ingress PE address is the IP address determined from the Global Administrator field of the VRF Route Import Extended Community that is carried in this route. Then, the egress PE finds the best unicast route to reach the ingress PE. The upstream node address is the IP address determined from the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community that is carried in this route.
アプリケーションがグローバルテーブルマルチキャストの場合、アップストリームノードアドレスを決定するために、出力PEはまず入力PEを決定します。入力PEを決定するために、出力PEはS / RPに到達するための最適なルートを決定します。入力PEアドレスは、このルートで伝送されるVRFルートインポート拡張コミュニティのグローバル管理者フィールドから決定されたIPアドレスです。次に、出力PEは、入力PEに到達するための最適なユニキャストルートを見つけます。アップストリームノードアドレスは、このルートで伝送されるエリア間P2MPセグメント化ネクストホップ拡張コミュニティのグローバル管理者フィールドから決定されたIPアドレスです。
If the P2MP FEC was derived from an MVPN or VPLS A-D route, and if the route carries a PMSI Tunnel attribute with the "Leaf Information Required" flag set, then the egress PE MUST originate a Leaf A-D route.
P2MP FECがMVPNまたはVPLS A-Dルートから派生し、ルートが「Leaf Information Required」フラグが設定されたPMSIトンネル属性を運ぶ場合、出力PEはリーフA-Dルートを発信する必要があります。
If the P2MP FEC was derived from a global table multicast (S/*,G), and the upstream node's address is not the same as the egress PE, then the egress PE MUST originate a Leaf A-D route.
P2MP FECがグローバルテーブルマルチキャスト（S / *、G）から派生し、アップストリームノードのアドレスが出力PEと同じでない場合、出力PEはリーフA-Dルートを発信する必要があります。
If the P2MP FEC was derived from MVPN or VPLS A-D routes, then the Route Key field of the Leaf A-D route contains the NLRI of the A-D route from which the P2MP FEC was derived. This follows procedures for constructing Leaf A-D routes described in [RFC6514] [RFC7117].
P2MP FECがMVPNまたはVPLS A-Dルートから派生した場合、Leaf A-DルートのRoute Keyフィールドには、P2MP FECが派生したA-DルートのNLRIが含まれます。これは、[RFC6514] [RFC7117]で説明されているリーフA-Dルートを構築する手順に従います。
If the application is global table multicast, then the MCAST-VPN NLRI of the Leaf A-D route is constructed as follows.
アプリケーションがグローバルテーブルマルチキャストの場合、Leaf A-DルートのMCAST-VPN NLRIは次のように構築されます。
The Route Key field of the MCAST-VPN NLRI has the following format:
MCAST-VPN NLRIのルートキーフィールドの形式は次のとおりです。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Ingress PE's IP Address |
+-----------------------------------+
RD is set to 0 for (S,G) state and all ones for (*,G) state, Multicast Source is set to S for (S,G) state or RP for (*,G) state, Multicast Group is set to G, and Multicast Source Length and Multicast Group Length are set to either 4 or 16 (depending on whether S/RP and G are IPv4 or IPv6 addresses).
RDは（S、G）状態の場合は0に設定され、（*、G）状態の場合はすべて1、マルチキャストソースは（S、G）状態の場合はSに、（*、G）状態の場合はRPに設定され、マルチキャストグループは設定されますからG、およびマルチキャストソース長とマルチキャストグループ長は4または16に設定されます（S / RPとGがIPv4アドレスかIPv6アドレスかによって異なります）。
The Ingress PE's IP address is determined as described in Section 6.1.
Ingress PEのIPアドレスは、セクション6.1の説明に従って決定されます。
The Originating Router's IP Address field of the MCAST-VPN NLRI is set to the address of the local PE (the PE that originates the route).
MCAST-VPN NLRIの発信元ルーターのIPアドレスフィールドは、ローカルPE（ルートを発信するPE）のアドレスに設定されます。
Thus, the entire MCAST-VPN NLRI of the route has the following format:
したがって、ルートのMCAST-VPN NLRI全体は次の形式になります。
+-----------------------------------+
| Route Type = 4 (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Ingress PE's IP Address |
+-----------------------------------+
| Originating Router's IP Address |
+-----------------------------------+
Note that the encoding of the MCAST-VPN NLRI for the Leaf A-D routes used for global table multicast is different from the encoding used by the Leaf A-D routes originated in response to S-PMSI or I-PMSI A-D routes. A router that receives a Leaf A-D route can distinguish between these two cases by examining the third octet of the MCAST-VPN NLRI of the route. If the value of this octet is 0x01, 0x02, or 0x03, then this Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route. If the value of this octet is either 0x00 or 0xff, and octets 3 through 10 contain either all 0x00 or all 0xff, then this is a Leaf A-D route used for global table multicast.
グローバルテーブルマルチキャストに使用されるリーフA-DルートのMCAST-VPN NLRIのエンコーディングは、S-PMSIまたはI-PMSI A-Dルートに応答して発信されたリーフA-Dルートで使用されるエンコーディングとは異なることに注意してください。リーフA-Dルートを受信するルーターは、ルートのMCAST-VPN NLRIの3番目のオクテットを調べることにより、これら2つのケースを区別できます。このオクテットの値が0x01、0x02、または0x03の場合、このLeaf A-DルートはS-PMSIまたはI-PMSI A-Dルートへの応答として発信されました。このオクテットの値が0x00または0xffであり、オクテット3〜10にすべて0x00またはすべて0xffが含まれている場合、これはグローバルテーブルマルチキャストに使用されるリーフA-Dルートです。
When the PE deletes (S,G)/(*,G) state that was created as a result of receiving PIM or IGMP messages on one of its IP multicast interfaces, if the PE previously originated a Leaf A-D route for that state, the PE SHOULD withdraw that route.
PEがそのIPマルチキャストインターフェイスの1つでPIMまたはIGMPメッセージを受信した結果として作成された（S、G）/（*、G）状態を削除するとき、PEがその状態のリーフADルートを以前に作成した場合、 PEはそのルートを撤回する必要があります。
An AS with an IPv4 network may provide global table multicast service for customers that use IPv6, and an AS with an IPv6 network may provide global table multicast service for customers that use IPv4. Therefore, the address family of the Ingress PE's IP Address field and the Originating Router's IP Address field in the Leaf A-D routes used for global table multicast MUST NOT be inferred from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes. The address family is determined from the length of the address (a length of 4 octets for IPv4 addresses or a length of 16 octets for IPv6 addresses).
IPv4ネットワークを使用するASは、IPv6を使用する顧客にグローバルテーブルマルチキャストサービスを提供し、IPv6ネットワークを使用するASは、IPv4を使用する顧客にグローバルテーブルマルチキャストサービスを提供します。したがって、グローバルテーブルマルチキャストに使用されるリーフA-Dルートの入力PEのIPアドレスフィールドと発信元ルーターのIPアドレスフィールドのアドレスファミリは、これらのルートの関連するMP_REACH_NLRI / MP_UNREACH_NLRI属性のAFIフィールドから推測してはなりません。アドレスファミリは、アドレスの長さ（IPv4アドレスの場合は4オクテットの長さ、IPv6アドレスの場合は16オクテットの長さ）から決定されます。
For example, if an AS with an IPv4 network is providing IPv6 multicast service to a customer, the Ingress PE's IP Address and Originating Router's IP Address in the Leaf A-D routes used for IPv6 global table multicast will be a 4-octet IPv4 address, even though the AFI of those routes will have the value 2.
たとえば、IPv4ネットワークのASがIPv6マルチキャストサービスを顧客に提供している場合、IPv6グローバルテーブルマルチキャストに使用されるリーフADルートの入力PEのIPアドレスと発信元ルーターのIPアドレスは、4オクテットのIPv4アドレスになります。ただし、これらのルートのAFIの値は2です。
Note that the Ingress PE's IP Address and the Originating Router's IP Address must be either both IPv4 or both IPv6 addresses; thus, they must be of the same length. Since the two variable-length fields (Multicast Source and Multicast Group) in the Leaf A-D routes used for global table multicast have their own Length field, from these two Length fields, and the Length field of the MCAST-VPN NLRI, one can compute the length of the Ingress PE's IP Address field and the Originating Router's IP Address field. If the computed length of these fields is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [RFC4760].
入力PEのIPアドレスと発信元ルーターのIPアドレスは、両方ともIPv4または両方のIPv6アドレスでなければなりません。したがって、それらは同じ長さでなければなりません。グローバルテーブルマルチキャストに使用されるリーフADルートの2つの可変長フィールド（マルチキャストソースとマルチキャストグループ）には、これら2つの長さフィールドとMCAST-VPN NLRIの長さフィールドから、独自の長さフィールドがあるため、入力PEのIPアドレスフィールドと発信元ルーターのIPアドレスフィールドの長さ。これらのフィールドの計算された長さが4でも16でもない場合、MP_REACH_NLRI属性は「正しくない」と見なされなければならず、[RFC4760]のセクション7で指定されているように処理されなければなりません（MUST）。
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD be set to the same IP address as the one carried in the Originating Router's IP Address field of the route.
ルートのMP_REACH_NLRI属性のNext Hopフィールドは、ルートのOriginating Router's IP Addressフィールドで運ばれるものと同じIPアドレスに設定されるべきです（SHOULD）。
When ingress replication is used to instantiate the egress area segment, the Leaf A-D route MUST carry a downstream-assigned label in the PMSI Tunnel attribute where the PMSI Tunnel Type is set to ingress replication. A PE MUST assign a distinct MPLS label for each Leaf A-D route originated by the PE.
入力レプリケーションを使用して出力エリアセグメントをインスタンス化する場合、リーフA-Dルートは、PMSIトンネルタイプが入力レプリケーションに設定されているPMSIトンネル属性でダウンストリーム割り当てのラベルを運ぶ必要があります。 PEは、PEから発信された各リーフA-Dルートに個別のMPLSラベルを割り当てる必要があります。
To constrain distribution of this route, the originating PE constructs an IP-based Route Target Extended Community by placing the IP address of the upstream node in the Global Administrator field of the Extended Community, with the Local Administrator field of this community set to 0. The originating PE then adds this Route Target Extended Community to this Leaf A-D route. The upstream node's address is determined as specified in Section 6.1.
このルートの配布を制限するために、元のPEは拡張コミュニティのグローバル管理者フィールドに上流ノードのIPアドレスを配置し、このコミュニティのローカル管理者フィールドを0に設定して、IPベースのルートターゲット拡張コミュニティを構築します。次に、元のPEはこのルートターゲット拡張コミュニティをこのリーフADルートに追加します。上流ノードのアドレスは、セクション6.1で指定されているように決定されます。
The PE then advertises this route to the upstream node.
次に、PEはこのルートを上流ノードにアドバタイズします。
This specification allows two options for supporting global table multicast that are initiated using PIM-SM in ASM mode. The first option does not carry IP multicast shared trees over the MPLS network. The second option does carry shared trees over the MPLS network and provides support for switching from shared trees to source trees.
この仕様では、ASMモードでPIM-SMを使用して開始されるグローバルテーブルマルチキャストをサポートするための2つのオプションを使用できます。最初のオプションは、MPLSネットワークを介してIPマルチキャスト共有ツリーを伝送しません。 2番目のオプションは、MPLSネットワークを介して共有ツリーを伝送し、共有ツリーからソースツリーへの切り替えをサポートします。
This option does not carry IP multicast shared trees over the MPLS network. Therefore, when an (egress) PE creates (*,G) state (as a result of receiving PIM or IGMP messages on one of its IP multicast interfaces), the PE does not propagate this state using Leaf A-D routes.
このオプションは、MPLSネットワークを介してIPマルチキャスト共有ツリーを伝送しません。したがって、（出力）PEが（*、G）状態を作成すると（IPマルチキャストインターフェイスの1つでPIMまたはIGMPメッセージを受信した結果）、PEはリーフA-Dルートを使用してこの状態を伝播しません。
Whenever an RP that is co-located with a PE discovers a new multicast source (as a result of receiving PIM Register or MSDP messages), the RP/PE SHOULD originate a BGP Source Active A-D route. Similarly, whenever, as a result of receiving MSDP messages, a PE that is not configured as an RP discovers a new multicast source, the PE SHOULD originate a BGP Source Active A-D route. The BGP Source Active A-D route carries a single MCAST-VPN NLRI constructed as follows:
PEと同じ場所にあるRPが（PIM RegisterまたはMSDPメッセージを受信した結果として）新しいマルチキャストソースを検出すると、RP / PEはBGP Source Active A-Dルートを開始する必要があります（SHOULD）。同様に、MSDPメッセージを受信した結果として、RPとして構成されていないPEが新しいマルチキャストソースを検出するたびに、PEはBGPソースアクティブA-Dルートを発信する必要があります（SHOULD）。 BGPソースアクティブA-Dルートは、次のように構築された単一のMCAST-VPN NLRIを伝送します。
+ The RD in this NLRI is set to 0.
+ このNLRIのRDは0に設定されています。
+ The Multicast Source field MUST be set to S. The Multicast Source Length field is set appropriately to reflect this.
+ Multicast SourceフィールドはSに設定する必要があります。MulticastSource Lengthフィールドは、これを反映するように適切に設定されています。
+ The Multicast Group field MUST be set to G. The Multicast Group Length field is set appropriately to reflect this.
+ Multicast GroupフィールドはGに設定する必要があります。MulticastGroup Lengthフィールドはこれを反映するように適切に設定されます。
The Route Target of this Source Active A-D route is an AS-specific Route Target Extended Community with the Global Administrator field set to the AS of the advertising RP/PE and the Local Administrator field set to 0.
このソースアクティブA-Dルートのルートターゲットは、AS固有のルートターゲット拡張コミュニティであり、グローバル管理者フィールドがアドバタイジングRP / PEのASに設定され、ローカル管理者フィールドが0に設定されています。
To constrain distribution of the Source Active A-D route to the AS of the advertising RP, this route SHOULD carry the NO_EXPORT Community ([RFC1997]).
ソースアクティブA-Dルートの配布をアドバタイジングRPのASに制限するには、このルートはNO_EXPORTコミュニティ（[RFC1997]）を伝送する必要があります（SHOULD）。
Using the normal BGP procedures, the Source Active A-D route is propagated to all other PEs within the AS.
通常のBGP手順を使用して、ソースアクティブA-DルートはAS内の他のすべてのPEに伝播されます。
Whenever the RP/PE discovers that the source is no longer active, the RP MUST withdraw the Source Active A-D route, if such a route was previously advertised by the RP.
RP / PEがソースがもはやアクティブでないことを発見するときはいつでも、そのようなルートが以前にRPによってアドバタイズされていた場合、RPはソースアクティブA-Dルートを撤回しなければなりません（MUST）。
As a result of receiving PIM or IGMP messages on one of its IP multicast interfaces, when an egress PE creates in its Tree Information Base (TIB) a new (*,G) entry with a non-empty outgoing interface list that contains one or more IP multicast interfaces, the PE MUST check if it has any Source Active A-D routes for that G. If there is such a route, S of that route is reachable via an MPLS interface, and the PE does not have (S,G) state in its TIB for (S,G) carried in the route, then the PE originates a Leaf A-D route carrying that (S,G), as specified in Section 6.2.2.
IPマルチキャストインターフェイスの1つでPIMまたはIGMPメッセージを受信した結果として、出力PEがツリー情報ベース（TIB）に、1つまたは複数を含む空でない発信インターフェイスリストを含む新しい（*、G）エントリを作成すると、より多くのIPマルチキャストインターフェイス、PEはそのGのソースアクティブADルートがあるかどうかを確認する必要があります。そのようなルートがある場合、そのルートのSはMPLSインターフェイス経由で到達可能であり、PEには（S、G）がありませんルートで運ばれる（S、G）のTIBの状態の場合、セクション6.2.2で指定されているように、PEはその（S、G）を運ぶリーフADルートを発信します。
When an egress PE receives a new Source Active A-D route, the PE MUST check if its TIB contains an (*,G) entry with the same G as carried in the Source Active A-D route. If such an entry is found, S is reachable via an MPLS interface, and the PE does not have (S,G) state in its TIB for (S,G) carried in the route, then the PE originates a Leaf A-D route carrying that (S,G), as specified in Section 6.2.2.
出力PEが新しいソースアクティブA-Dルートを受信すると、PEは、そのTIBに、ソースアクティブA-Dルートで運ばれたのと同じGの（*、G）エントリが含まれているかどうかを確認する必要があります。そのようなエントリが見つかった場合、SはMPLSインターフェイスを介して到達可能であり、PEはルートで運ばれる（S、G）のTIBに（S、G）状態を持たず、PEはセクション6.2.2で指定されている（S、G）。
Creation and deletion of (S,G,rpt) state on a PE that resulted from receiving PIM messages on one of its IP multicast interfaces do not result in any BGP actions by the PE.
IPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果としてPEで（S、G、rpt）状態を作成および削除しても、PEによるBGPアクションは発生しません。
This option does carry IP multicast shared trees over the MPLS network. Therefore, when an egress PE creates (*,G) state (as a result of receiving PIM or IGMP messages on one of its IP multicast interfaces), the PE does propagate this state using Leaf A-D routes.
このオプションは、MPLSネットワークを介してIPマルチキャスト共有ツリーを伝送します。したがって、出力PEが（*、G）状態を作成すると（IPマルチキャストインターフェイスの1つでPIMまたはIGMPメッセージを受信した結果として）、PEはリーフA-Dルートを使用してこの状態を伝達します。
Whenever a PE creates an (S,G) state as a result of receiving Leaf A-D routes associated with the global table multicast service, if S is reachable via one of the IP multicast-capable interfaces, and the PE determines that G is in the PIM-SM in ASM mode range, the PE MUST originate a BGP Source Active A-D route. The route carries a single MCAST-VPN NLRI constructed as follows:
グローバルテーブルマルチキャストサービスに関連付けられたリーフADルートを受信した結果、PEが（S、G）状態を作成するときはいつでも、IPマルチキャスト対応インターフェイスの1つを介してSに到達でき、PEがGがASMモード範囲のPIM-SM、PEはBGPソースアクティブADルートを発信する必要があります。ルートは、次のように構築された単一のMCAST-VPN NLRIを伝送します。
+ The RD in this NLRI is set to 0.
+ このNLRIのRDは0に設定されています。
+ The Multicast Source field MUST be set to S. The Multicast Source Length field is set appropriately to reflect this.
+ Multicast SourceフィールドはSに設定する必要があります。MulticastSource Lengthフィールドは、これを反映するように適切に設定されています。
+ The Multicast Group field MUST be set to G. The Multicast Group Length field is set appropriately to reflect this.
+ Multicast GroupフィールドはGに設定する必要があります。MulticastGroup Lengthフィールドはこれを反映するように適切に設定されます。
The Route Target of this Source Active A-D route is an AS-specific Route Target Extended Community with the Global Administrator field set to the AS of the advertising PE and the Local Administrator field set to 0.
このソースアクティブA-Dルートのルートターゲットは、AS固有のルートターゲット拡張コミュニティで、グローバル管理者フィールドがアドバタイジングPEのASに設定され、ローカル管理者フィールドが0に設定されています。
To constrain distribution of the Source Active A-D route to the AS of the advertising PE, this route SHOULD carry the NO_EXPORT Community [RFC1997].
ソースアクティブA-Dルートの配布をアドバタイジングPEのASに制限するには、このルートはNO_EXPORTコミュニティ[RFC1997]を伝送する必要があります（SHOULD）。
Using the normal BGP procedures, the Source Active A-D route is propagated to all other PEs within the AS.
通常のBGP手順を使用して、ソースアクティブA-DルートはAS内の他のすべてのPEに伝播されます。
Whenever the PE deletes the (S,G) state that was previously created as a result of receiving a Leaf A-D route for (S,G), the PE that deletes the state MUST also withdraw the Source Active A-D route, if such a route was advertised when the state was created.
（S、G）のリーフADルートを受信した結果として以前に作成された（S、G）状態をPEが削除するときは常に、状態を削除するPEは、ソースアクティブADルートも撤回する必要があります（そのようなルートの場合）。状態が作成されたときに宣伝されました。
Procedures for receiving BGP Source Active A-D routes are the same as with Option 1.
BGPソースアクティブA-Dルートを受信する手順は、オプション1の場合と同じです。
After receiving a new Source Active A-D route for (S,G), if a PE determines that (a) it has the (*,G) entry in its TIB, (b) the incoming interface (iif) list for that entry contains one of the IP interfaces, (c) an MPLS LSP is in the outgoing interface (oif) list for that entry, and (d) the PE does not originate a Leaf A-D route for (S,G), then the PE MUST transition the (S,G,rpt) downstream state to the Prune state. [Conceptually the PIM state machine on the PE will act "as if" it had received Prune(S,G,Rpt) from some other PE, without actually having received one.] Depending on the (S,G,rpt) state on the iifs, this may result in the PE using PIM procedures to prune S off the Shared (*,G) tree.
（S、G）の新しいソースアクティブADルートを受信した後、PEが（a）TIBに（*、G）エントリがあると判断した場合、（b）そのエントリの着信インターフェイス（iif）リストにIPインターフェイスの1つ、（c）MPLS LSPがそのエントリの発信インターフェイス（oif）リストにあり、（d）PEが（S、G）のリーフADルートを開始しない場合、PEは移行する必要がある（S、G、rpt）ダウンストリーム状態からプルーン状態。 [概念的には、PE上のPIMステートマシンは、他のPEからPrune（S、G、Rpt）を実際に受信することなく受信したかのように動作します。]上の（S、G、rpt）状態によってiifの場合、これにより、PEはPIM手順を使用してSを共有（*、G）ツリーから削除します。
Transitioning the state machine to the Prune state SHOULD be done after a delay that is controlled by a timer. The value of the timer MUST be configurable. The purpose of this timer is to ensure that S is not pruned off the shared tree until all PEs have had time to receive the Source Active A-D route for (S,G).
状態機械をプルーン状態に移行することは、タイマーによって制御される遅延の後に行われる必要があります。タイマーの値は構成可能でなければなりません。このタイマーの目的は、すべてのPEが（S、G）のソースアクティブA-Dルートを受信する時間を確保するまで、Sが共有ツリーからプルーニングされないようにすることです。
The PE MUST keep the (S,G,rpt) downstream state machine in the Prune state for as long as (a) the outgoing interface list (oif) for (*,G) contains an MPLS LSP, (b) the PE has at least one Source Active A-D route for (S,G), and (c) the PE does not originate the Leaf A-D route for (S,G). Once any of these conditions become no longer valid, the PE MUST transition the (S,G,rpt) downstream state machine to the NoInfo state.
PEは、（a、（*、G）の発信インターフェイスリスト（oif）にMPLS LSPが含まれている限り、（S、G、rpt）ダウンストリームステートマシンをプルーン状態に維持する必要があります（b）PEは（S、G）の少なくとも1つのソースアクティブADルート、および（c）PEが（S、G）のリーフADルートを発信していません。これらの条件のいずれかが有効でなくなると、PEは（S、G、rpt）ダウンストリームステートマシンをNoInfoステートに移行する必要があります。
Note that, except for the scenario described in the first paragraph of this section, in all scenarios relying solely on PIM procedures on the PE is sufficient to ensure the correct behavior when pruning sources off the shared tree.
このセクションの最初の段落で説明したシナリオを除いて、すべてのシナリオで、PEのPIMプロシージャのみに依存することで、共有ツリーからソースをプルーニングするときの正しい動作を確保できます。
Creation and deletion of (S,G,rpt) state on a PE that resulted from receiving PIM messages on one of its IP multicast interfaces do not result in any BGP actions by the PE.
IPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果としてPEで（S、G、rpt）状態を作成および削除しても、PEによるBGPアクションは発生しません。
This section describes the egress ABR procedures for constructing segmented inter-area P2MP LSPs.
このセクションでは、セグメント化されたエリア間P2MP LSPを構築するための出力ABR手順について説明します。
When an egress ABR receives a Leaf A-D route and the Route Target Extended Community carried by the route contains the IP address of this ABR, the following procedures will be executed.
出力ABRがリーフA-Dルートを受信し、ルートによって運ばれるルートターゲット拡張コミュニティにこのABRのIPアドレスが含まれている場合、次の手順が実行されます。
If the value of the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is either 0x01, 0x02, or 0x03, this indicates that the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route (see Section 6.2.2). In this case, the egress ABR MUST find an S-PMSI or I-PMSI route whose NLRI has the same value as the Route Key field of the received Leaf A-D route. If such a matching route is found, then the Leaf A-D route MUST be accepted. If the Leaf A-D route is accepted and if it is the first Leaf A-D route update for the Route Key field in the route, or the withdrawal of the last Leaf A-D route for the Route Key field, then the following procedures will be executed.
受信したリーフADルートのMCAST-VPN NLRIの3番目のオクテットの値が0x01、0x02、または0x03のいずれかである場合、これはリーフADルートがS-PMSIまたはI-PMSI ADルートに応答して発信されたことを示します（セクション6.2.2を参照）。この場合、出力ABRは、NLRIが受信したリーフA-Dルートのルートキーフィールドと同じ値を持つS-PMSIまたはI-PMSIルートを検出する必要があります。そのような一致するルートが見つかった場合は、リーフA-Dルートを受け入れる必要があります。リーフA-Dルートが受け入れられ、ルートのルートキーフィールドの最初のリーフA-Dルート更新である場合、またはルートキーフィールドの最後のリーフA-Dルートの撤回である場合、次の手順が実行されます。
If the RD of the received Leaf A-D route is set to all zeros or all ones, then the received Leaf A-D route is for the global table multicast service.
受信したリーフA-DルートのRDがすべてゼロまたはすべて1に設定されている場合、受信したリーフA-Dルートはグローバルテーブルマルチキャストサービス用です。
If the received Leaf A-D route is the first Leaf A-D route update for the Route Key field carried in the route, then the egress ABR originates a Leaf A-D route, whose MCAST-VPN NLRI is constructed as follows.
受信したリーフA-Dルートがルートで伝送されるルートキーフィールドの最初のリーフA-Dルート更新である場合、出力ABRはリーフA-Dルートを発信し、そのMCAST-VPN NLRIは次のように構成されます。
The Route Key field of the MCAST-VPN NLRI is the same as the Route Key field of the MCAST-VPN NLRI of the received Leaf A-D route. The Originating Router's IP Address field of the MCAST-VPN NLRI is set to the address of the local ABR (the ABR that originates the route).
MCAST-VPN NLRIのルートキーフィールドは、受信したリーフA-DルートのMCAST-VPN NLRIのルートキーフィールドと同じです。 MCAST-VPN NLRIの発信元ルーターのIPアドレスフィールドは、ローカルABR（ルートを発信するABR）のアドレスに設定されます。
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD be set to the same IP address as the one carried in the Originating Router's IP Address field of the route.
ルートのMP_REACH_NLRI属性のNext Hopフィールドは、ルートのOriginating Router's IP Addressフィールドで運ばれるものと同じIPアドレスに設定されるべきです（SHOULD）。
To constrain distribution of this route, the originating egress ABR constructs an IP-based Route Target Extended Community by placing the IP address of the upstream node in the Global Administrator field of the Extended Community, with the Local Administrator field of this Extended Community set to 0, and sets the Extended Communities attribute of this Leaf A-D route to that Extended Community.
このルートの配布を制限するために、発信側の出力ABRは、上流ノードのIPアドレスを拡張コミュニティのグローバル管理者フィールドに配置し、この拡張コミュニティのローカル管理者フィールドを次のように設定して、IPベースのルートターゲット拡張コミュニティを構築します。 0、およびこのリーフADルートの拡張コミュニティ属性をその拡張コミュニティに設定します。
The upstream node's IP address is the IP address determined from the Global Administrator field of the Inter-Area P2MP Segmented Next-Hop Extended Community, where this Extended Community is obtained as follows. When the Leaf A-D route is for MVPN or VPLS, this Extended Community is the one carried in the I-PMSI/S-PMSI A-D route that matches the Leaf A-D route. When the Leaf A-D route is for global table multicast, this Extended Community is the one carried in the best unicast route to the Ingress PE. The Ingress PE address is determined from the received Leaf A-D route. The best unicast route MUST first be determined from multicast SAFI, i.e., SAFI 2 routes, if present.
上流ノードのIPアドレスは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティのグローバル管理者フィールドから決定されたIPアドレスであり、この拡張コミュニティは次のように取得されます。リーフA-DルートがMVPNまたはVPLS用である場合、この拡張コミュニティは、リーフA-Dルートと一致するI-PMSI / S-PMSI A-Dルートで伝送されるものです。リーフA-Dルートがグローバルテーブルマルチキャスト用である場合、この拡張コミュニティは、入力PEへの最適なユニキャストルートで運ばれるものです。入力PEアドレスは、受信したリーフA-Dルートから決定されます。最適なユニキャストルートは、マルチキャストSAFI、つまり存在する場合はSAFI 2ルートから最初に決定する必要があります。
The ABR then advertises this Leaf A-D route to the upstream node in the backbone area.
次に、ABRはこのリーフA-Dルートをバックボーンエリアの上流ノードにアドバタイズします。
Mechanisms specified in [RFC4684] for constrained BGP route distribution can be used along with this specification to ensure that only the needed PE/ABR will have to process a said Leaf A-D route.
[RFC4684]で指定された、制約付きBGPルート配信のメカニズムをこの仕様とともに使用して、必要なPE / ABRのみが上記のリーフA-Dルートを処理する必要があることを確認できます。
When ingress replication is used to instantiate the backbone area segment, the Leaf A-D route originated by the egress ABR MUST carry a downstream-assigned label in the PMSI Tunnel attribute where the Tunnel Type is set to ingress replication. The ABR MUST assign a distinct MPLS label for each Leaf A-D route that it originates.
入力レプリケーションを使用してバックボーンエリアセグメントをインスタンス化する場合、出力ABRによって開始されたリーフA-Dルートは、トンネルタイプが入力レプリケーションに設定されているPMSIトンネル属性でダウンストリーム割り当てのラベルを運ぶ必要があります。 ABRは、発信元である各リーフA-Dルートに個別のMPLSラベルを割り当てなければなりません（MUST）。
In order to support global table multicast, an egress ABR MUST auto-configure an import AS-based Route Target Extended Community with the Global Administrator field set to the AS of the ABR and the Local Administrator field set to 0.
グローバルテーブルマルチキャストをサポートするために、出力ABRは、グローバル管理者フィールドをABRのASに設定し、ローカル管理者フィールドを0に設定して、インポートASベースのルートターゲット拡張コミュニティを自動設定する必要があります。
If the received Leaf A-D route is the withdrawal of the last Leaf A-D route for the Route Key carried in the route, then the egress ABR must withdraw the Leaf A-D route associated with that Route Key that has been previously advertised by the egress ABR in the backbone area.
受信したリーフADルートがルートで運ばれるルートキーの最後のリーフADルートの撤回である場合、出力ABRは、以前に出口ABRによってアドバタイズされたそのルートキーに関連付けられたリーフADルートを撤回する必要があります。バックボーンエリア。
This section describes procedures for using intra-area P2MP LSPs in the egress area. The procedures that are common to both P2MP RSVP-TE and P2MP LDP are described first, followed by procedures that are specific to the signaling protocol.
このセクションでは、出力エリアでエリア内P2MP LSPを使用する手順について説明します。 P2MP RSVP-TEとP2MP LDPの両方に共通の手順を最初に説明してから、シグナリングプロトコルに固有の手順を説明します。
When P2MP LSPs are used as the intra-area LSPs, note that an existing intra-area P2MP LSP may be used solely for a particular inter-area P2MP service LSP or for other inter-area P2MP service LSPs as well.
P2MP LSPがエリア内LSPとして使用される場合、既存のエリア内P2MP LSPは、特定のエリア間P2MPサービスLSPまたは他のエリア間P2MPサービスLSPにのみ使用される場合があることに注意してください。
The choice between the two options is purely local to the egress ABR. The first option provides one-to-one mapping between inter-area P2MP service LSPs and intra-area P2MP LSPs; the second option provides many-to-one mapping, thus allowing the aggregation of forwarding state.
2つのオプションの選択は、出力ABRに対して純粋にローカルです。最初のオプションは、エリア間P2MPサービスLSPとエリア内P2MP LSP間の1対1のマッピングを提供します。 2番目のオプションは多対1のマッピングを提供し、転送状態の集約を可能にします。
If the value of the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is either 0x01, 0x02, or 0x03, this indicates that the Leaf A-D route was originated in response to an MVPN or VPLS S-PMSI or I-PMSI A-D route (see Section 6.2.2). In this case, the ABR MUST re-advertise in the egress area the MVPN/VPLS A-D route that matches the Leaf A-D route to signal the binding of the intra-area P2MP LSP to the inter-area P2MP service LSP. This must be done if and only if (a) such a binding hasn't already been advertised or (b) the binding has changed. The re-advertised route MUST carry the Inter-area P2MP Segmented Next-Hop Extended Community.
受信したリーフADルートのMCAST-VPN NLRIの3番目のオクテットの値が0x01、0x02、または0x03のいずれかである場合、これはリーフADルートがMVPNまたはVPLS S-PMSIまたはI- PMSI ADルート（セクション6.2.2を参照）。この場合、ABRは、エリア内P2MP LSPのエリア間P2MPサービスLSPへのバインディングをシグナリングするために、リーフA-Dルートと一致するMVPN / VPLS A-Dルートを出口エリアで再アドバタイズする必要があります。これは、（a）そのようなバインディングがまだ通知されていない場合、または（b）バインディングが変更された場合にのみ行う必要があります。再アドバタイズされたルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを運ぶ必要があります。
The PMSI Tunnel attribute of the re-advertised route specifies either an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted at the ABR and MUST also carry an upstream-assigned MPLS label. The upstream-assigned MPLS label MUST be set to Implicit NULL if the mapping between the inter-area P2MP service LSP and the intra-area P2MP LSP is one-to-one. If the mapping is many-to-one, the intra-area segment of the inter-area P2MP service LSP (referred to as the
再アドバタイズされたルートのPMSIトンネル属性は、ABRをルートとするエリア内P2MP RSVP-TE LSPまたはエリア内P2MP LDP LSPのいずれかを指定し、アップストリーム割り当てMPLSラベルも運ぶ必要があります。エリア間P2MPサービスLSPとエリア内P2MP LSPの間のマッピングが1対1の場合、アップストリームに割り当てられたMPLSラベルは暗黙のNULLに設定する必要があります。マッピングが多対1の場合、エリア間P2MPサービスLSPのエリア内セグメント（
"inner" P2MP LSP) is constructed by nesting the inter-area P2MP service LSP in an intra-area P2MP LSP (referred to as the "outer" intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream-assigned MPLS labels [RFC5332].
「内部」P2MP LSP）は、上流に割り当てられたMPLSに基づくP2MP LSP階層を使用して、エリア間P2MP LSP（「外部」エリア内P2MP LSPと呼ばれる）内にエリア間P2MPサービスLSPをネストすることにより構築されます。ラベル[RFC5332]。
If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried over a given intra-area P2MP LSP, each of these segments MUST carry a distinct upstream-assigned label, even if all these service LSPs are for (C-S/*,C-G/*)s from the same MVPN/VPLS. Therefore, an ABR maintains a Label Forwarding Information Base (LFIB) state for each such S-PMSI traversing the ABR (that applies to both the ingress and the egress ABRs).
複数のMVPNまたはVPLS S-PMSIサービスLSPのセグメントが特定のエリア内P2MP LSPで伝送される場合、これらすべてのサービスLSPが（CS / *、CG / *）s同じMVPN / VPLSから。したがって、ABRは、ABRを通過するそのような各S-PMSIのラベル転送情報ベース（LFIB）状態を維持します（これは、入力ABRと出力ABRの両方に適用されます）。
When the RD of the received Leaf A-D route is set to all zeros or all ones, this is the case of inter-area P2MP service LSP being associated with the global table multicast service. The procedures for this are described below.
受信したリーフA-DルートのRDがすべてゼロまたはすべて1に設定されている場合、これは、エリア間P2MPサービスLSPがグローバルテーブルマルチキャストサービスに関連付けられている場合です。この手順を以下に説明します。
This section applies only if it is desired to send a particular (S,G) or (*,G) global table multicast flow to only those egress PEs that have receivers for that multicast flow.
このセクションは、特定の（S、G）または（*、G）グローバルテーブルマルチキャストフローを、そのマルチキャストフローのレシーバーを持つ出力PEのみに送信する必要がある場合にのみ適用されます。
If the egress ABR has not previously received (and re-advertised) an S-PMSI A-D route for (S,G) or (*,G) that has been originated by an ingress PE/ASBR (see Section 9.1), then the egress ABR MUST originate an S-PMSI A-D route. The PMSI Tunnel attribute of the route MUST contain the identity of the intra-area P2MP LSP and an upstream-assigned MPLS label (although this label may be an Implicit NULL -- see Section 3). The RD, Multicast Source Length, Multicast Source, Multicast Group Length (1 octet), and Multicast Group fields of the NLRI of this route are the same as those of the received Leaf A-D route. The Originating Router's IP Address field in the S-PMSI A-D route is the same as the Ingress PE's IP Address field in the received Leaf A-D route. The Route Target of this route is an AS-specific Route Target Extended Community with the Global Administrator field set to the AS of the advertising ABR and the Local Administrator field set to 0. The route MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community is constructed following the procedures in Section 4.
出力PEが（S、G）または（*、G）のS-PMSI ADルートを以前に受信（および再アドバタイズ）していない場合、入力PE / ASBR（セクション9.1を参照）出力ABRはS-PMSI ADルートを発信する必要があります。ルートのPMSIトンネル属性には、エリア内P2MP LSPと上流に割り当てられたMPLSラベルのIDが含まれている必要があります（ただし、このラベルは暗黙のNULLである可能性があります-セクション3を参照）。このルートのNLRIのRD、マルチキャストソース長、マルチキャストソース、マルチキャストグループ長（1オクテット）、およびマルチキャストグループフィールドは、受信したリーフA-Dルートのフィールドと同じです。 S-PMSI A-Dルートの発信元ルーターのIPアドレスフィールドは、受信したリーフA-Dルートの入力PEのIPアドレスフィールドと同じです。このルートのルートターゲットは、AS固有のルートターゲット拡張コミュニティであり、グローバル管理者フィールドがアドバタイジングABRのASに設定され、ローカル管理者フィールドが0に設定されています。ルートは、エリア間P2MPセグメント化ネクストホップを運ぶ必要があります拡張コミュニティ。この拡張コミュニティは、セクション4の手順に従って構築されます。
The egress ABR MUST advertise this route into the egress area. PEs in the egress area that participate in the global table multicast will import this route based on the Route Target carried by the route.
出力ABRは、このルートを出力エリアにアドバタイズする必要があります。グローバルテーブルマルチキャストに参加する出力エリア内のPEは、ルートが運ぶルートターゲットに基づいてこのルートをインポートします。
A PE in the egress area that originated the Leaf A-D route SHOULD join the P2MP LSP advertised in the PMSI Tunnel attribute of the S-PMSI A-D route.
リーフA-Dルートを発信した出力エリアのPEは、S-PMSI A-DルートのPMSIトンネル属性でアドバタイズされるP2MP LSPに参加する必要があります（SHOULD）。
It may be desirable for an ingress PE to carry multiple multicast flows associated with the global table multicast over the same inter-area P2MP service LSP. This can be achieved using wildcard, i.e., (*,*) S-PMSI A-D routes [RFC6625]. An ingress PE MAY advertise a wildcard S-PMSI A-D route as described in Section 9.
入力PEが、同じエリア間P2MPサービスLSPを介してグローバルテーブルマルチキャストに関連付けられた複数のマルチキャストフローを伝送することが望ましい場合があります。これは、ワイルドカード、つまり（*、*）S-PMSI A-Dルート[RFC6625]を使用して実現できます。入力PEは、セクション9で説明されているように、ワイルドカードS-PMSI A-Dルートをアドバタイズできます（MAY）。
If the ingress PE originates a wildcard S-PMSI A-D route, and the egress ABR receives this route from the ingress ABR, then the egress ABR either (a) MUST re-advertise this route into the egress area with the PMSI Tunnel attribute containing the identifier of the intra-area P2MP LSP in the egress area and an upstream-assigned label (note that this label may be an Implicit NULL -- see Section 3) assigned to the inter-area wildcard S-PMSI or (b) MUST be able to disaggregate traffic carried over the wildcard S-PMSI onto the egress area (S,G) or (*,G) S-PMSIs. The procedures for such disaggregation require IP processing on the egress ABRs.
入力PEがワイルドカードS-PMSI ADルートを発信し、出力ABRが入力ABRからこのルートを受信した場合、出力ABRは（a）を含むPMSIトンネル属性でこのルートを出力エリアに再アドバタイズする必要があります出力エリア内のエリア内P2MP LSPの識別子、および上流に割り当てられたラベル（このラベルは暗黙的なNULLである可能性があることに注意してください-セクション3を参照）は、エリア間ワイルドカードS-PMSIに割り当てられるか、または（b）ワイルドカードS-PMSIを介して伝送されるトラフィックを出力エリア（S、G）または（*、G）S-PMSIに分解できます。このような分解の手順では、出力ABRでのIP処理が必要です。
If the egress ABR advertises a wildcard S-PMSI A-D route into the egress area, this route MUST carry an AS-specific Route Target Extended Community with the Global Administrator field set to the AS of the advertising ABR and the Local Administrator field set to 0. PEs in the egress area that participate in the global table multicast will import this route.
出力ABRがワイルドカードS-PMSI ADルートを出力エリアにアドバタイズする場合、このルートは、グローバル管理者フィールドがアドバタイジングABRのASに設定され、ローカル管理者フィールドが0に設定されたAS固有のルートターゲット拡張コミュニティを運ぶ必要があります。 。グローバルテーブルマルチキャストに参加する出力エリアのPEは、このルートをインポートします。
A PE in the egress area SHOULD join the P2MP LSP advertised in the PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the Originating Router's IP Address field in the S-PMSI A-D route has the same value as the Ingress PE's IP Address in at least one of the Leaf A-D routes for global table multicast originated by the PE and (b) the upstream ABR for the Ingress PE's IP address in that Leaf A-D route is the egress ABR that advertises the wildcard S-PMSI A-D route.
出力エリアのPEは、（a）S-PMSI ADルートの発信元ルーターのIPアドレスフィールドが入力PEと同じ値である場合、ワイルドカードS-PMSI ADルートのPMSIトンネル属性でアドバタイズされるP2MP LSPに参加する必要があります（SHOULD）。 PEによって発信されたグローバルテーブルマルチキャストの少なくとも1つのリーフADルートのIPアドレス、および（b）そのリーフADルートの入力PEのIPアドレスのアップストリームABRは、ワイルドカードS-PMSI ADルートをアドバタイズする出力ABRです。 。
If the mapping between the inter-area P2MP service LSP for global table multicast service and the intra-area P2MP LSP is many-to-one, then an egress PE must be able to determine whether a given multicast packet for a particular (S,G) is received from the "expected" upstream node. The expected node is the node towards which the Leaf A-D route is sent by the egress PE. Packets received from another upstream node for that (S,G) MUST be dropped. To allow the egress PE to determine the sender upstream node, the intra-area P2MP LSP MUST be signaled with no Penultimate Hop Popping (PHP), when the mapping between the inter-area P2MP service LSP for global table multicast service and the intra-area P2MP LSP is many-to-one.
グローバルテーブルマルチキャストサービスのエリア間P2MPサービスLSPとエリア内P2MP LSPの間のマッピングが多対1の場合、出力PEは、特定の（S、 G）「予想される」上流ノードから受信されます。予期されるノードは、リーフPEによってリーフA-Dルートが送信されるノードです。その（S、G）の別のアップストリームノードから受信したパケットはドロップする必要があります。出力PEが送信者の上流ノードを決定できるようにするには、グローバルテーブルマルチキャストサービスのエリア間P2MPサービスLSPとイントラエリアP2MP LSPの間のマッピングが行われるときに、エリア内P2MP LSPがPenultimate Hop Popping（PHP）なしでシグナリングされる必要があります。エリアP2MP LSPは多対1です。
Further, the egress ABR MUST first push onto the label stack the upstream-assigned label advertised in the S-PMSI A-D route, if the label is not the Implicit NULL.
さらに、ラベルがインプリシットNULLでない場合、出力ABRはまず、S-PMSI A-Dルートでアドバタイズされる上流割り当てラベルをラベルスタックにプッシュする必要があります。
The above procedures are sufficient if P2MP LDP LSPs are used as the intra-area P2MP LSP in the egress area.
上記の手順は、P2MP LDP LSPが出力エリアのエリア内P2MP LSPとして使用される場合に十分です。
If P2MP RSVP-TE LSP is used as the intra-area LSP in the egress area, then the egress ABR can either (a) graft the leaf (whose IP address is specified in the received Leaf A-D route) into an existing P2MP LSP rooted at the egress ABR, and use that LSP for carrying traffic for the inter-area segmented P2MP service LSP or (b) originate a new P2MP LSP to be used for carrying (S,G).
P2MP RSVP-TE LSPが出力エリアのエリア内LSPとして使用される場合、出力ABRは、（a）リーフ（IPアドレスが受信されたリーフADルートで指定されている）を既存のP2MP LSPにルート化することができます。出力ABRで、そのLSPを使用してエリア間セグメント化P2MPサービスLSPのトラフィックを伝送するか、または（b）伝送に使用する新しいP2MP LSPを発信します（S、G）。
When the RD of the received Leaf A-D route is all zeros or all ones, the procedures are as described in Section 7.2.2.
受信したリーフA-DルートのRDがすべて0または1の場合、手順は7.2.2項に記載されています。
Note also that the SESSION object that the egress ABR would use for the intra-area P2MP LSP need not encode the P2MP FEC from the received Leaf A-D route.
また、出力ABRがエリア内P2MP LSPに使用するSESSIONオブジェクトは、受信したリーフA-DルートからのP2MP FECをエンコードする必要がないことにも注意してください。
When ingress replication is used to instantiate the egress area segment, the Leaf A-D route advertised by the egress PE MUST carry a downstream-assigned label in the PMSI Tunnel attribute where the Tunnel Type is set to ingress replication. We will call this label the egress PE downstream-assigned label.
入力レプリケーションを使用して出力エリアセグメントをインスタンス化する場合、出力PEによってアドバタイズされるリーフA-Dルートは、トンネルタイプが入力レプリケーションに設定されているPMSIトンネル属性でダウンストリーム割り当てラベルを運ぶ必要があります。このラベルを出力PEダウンストリーム割り当てラベルと呼びます。
The egress ABR MUST forward packets received from the backbone area intra-area segment, for a particular inter-area P2MP LSP, to all the egress PEs from which the egress ABR has imported a Leaf A-D route for the inter-area P2MP LSP. A packet to a particular egress PE is encapsulated, by the egress ABR, using an MPLS label stack the bottom label of which is the egress PE downstream-assigned label. The top label is the P2P RSVP-TE or the MP2P LDP label to reach the egress PE.
出力ABRは、特定のエリア間P2MP LSPのバックボーンエリア内エリアセグメントから受信したパケットを、出力ABRがエリア間P2MP LSPのリーフA-Dルートをインポートしたすべての出力PEに転送する必要があります。特定の出力PEへのパケットは、出力ABRによって、最下部のラベルが出力PEダウンストリーム割り当てラベルであるMPLSラベルスタックを使用してカプセル化されます。最上位ラベルは、出力PEに到達するためのP2P RSVP-TEまたはMP2P LDPラベルです。
Note that these procedures ensure that an egress PE always receives packets only from the upstream node expected by the egress PE.
これらの手順により、出力PEが常に期待する上流ノードからのみ、出力PEがパケットを受信することに注意してください。
When an ingress ABR receives a Leaf A-D route and the Route Target Extended Community carried by the route contains the IP address of this ABR, the ingress ABR follows the same procedures as in Section 7, with egress ABR replaced by ingress ABR, backbone area replaced by ingress area, and backbone area segment replaced by ingress area segment.
入力ABRがリーフADルートを受信し、ルートによって運ばれるルートターゲット拡張コミュニティにこのABRのIPアドレスが含まれている場合、入力ABRはセクション7と同じ手順に従い、出力ABRを入力ABRに置き換え、バックボーンエリアを置き換えますイングレスエリアによって、バックボーンエリアセグメントはイングレスエリアセグメントに置き換えられます。
In order to support global table multicast, the ingress ABR MUST be auto-configured with an import AS-based Route Target Extended Community whose Global Administrator field is set to the AS of the ABR and whose Local Administrator field is set to 0.
グローバルテーブルマルチキャストをサポートするには、グローバル管理者フィールドがABRのASに設定され、ローカル管理者フィールドが0に設定されているインポートASベースのルートターゲット拡張コミュニティを使用して、入力ABRを自動設定する必要があります。
The procedures for binding the backbone area segment of an inter-area P2MP LSP to the intra-area P2MP LSP in the backbone area are the same as in Sections 7 and 7.2, with egress PE being replaced by egress ABR, egress ABR being replaced by ingress ABR, and egress area being replaced by backbone area. This applies to the inter-area P2MP LSPs associated with either MVPN, VPLS, or global table multicast.
エリア間P2MP LSPのバックボーンエリアセグメントをバックボーンエリアのエリア内P2MP LSPにバインドする手順は、セクション7および7.2と同じです。出力PEは出力ABRに、出力ABRは入力ABR、およびバックボーンエリアで置き換えられる出力エリア。これは、MVPN、VPLS、またはグローバルテーブルマルチキャストのいずれかに関連付けられているエリア間P2MP LSPに適用されます。
It is to be noted that, in the case of global table multicast, if the backbone area uses wildcard S-PMSI, then the egress area also SHOULD use wildcard S-PMSI for global table multicast, or the egress ABRs MUST be able to disaggregate traffic carried over the wildcard S-PMSI onto the egress area (S,G) or (*,G) S-PMSIs. The procedures for such disaggregation require IP processing on the egress ABRs.
グローバルテーブルマルチキャストの場合、バックボーンエリアでワイルドカードS-PMSIを使用すると、出力エリアでもグローバルテーブルマルチキャストにワイルドカードS-PMSIを使用する必要があります（SHOULD）。または、出力ABRは分解できる必要があります。ワイルドカードS-PMSIを介して出力エリア（S、G）または（*、G）S-PMSIに伝送されるトラフィック。このような分解の手順では、出力ABRでのIP処理が必要です。
When ingress replication is used to instantiate the backbone area segment, the Leaf A-D route advertised by the egress ABR MUST carry a downstream-assigned label in the PMSI Tunnel attribute where the Tunnel Type is set to ingress replication. We will call this the egress ABR downstream-assigned label. The egress ABR MUST assign a distinct MPLS label for each Leaf A-D route originated by the ABR.
入力レプリケーションを使用してバックボーンエリアセグメントをインスタンス化する場合、出力ABRによってアドバタイズされるリーフA-Dルートは、トンネルタイプが入力レプリケーションに設定されているPMSI Tunnel属性でダウンストリーム割り当てラベルを運ぶ必要があります。これを出力ABRダウンストリーム割り当てラベルと呼びます。出力ABRは、ABRから発信された各リーフA-Dルートに個別のMPLSラベルを割り当てなければなりません（MUST）。
The ingress ABR MUST forward packets received from the ingress area intra-area segment, for a particular inter-area P2MP LSP, to all the egress ABRs from which the ingress ABR has imported a Leaf A-D route for the inter-area P2MP LSP. A packet to a particular egress ABR is encapsulated, by the ingress ABR, using an MPLS label stack the bottom label of which is the egress ABR downstream-assigned label.
入力ABRは、特定のエリア間P2MP LSPについて、イングレスエリア内セグメントから受信したパケットを、エリア間P2MP LSPのリーフA-Dルートをインポートしたすべての出力ABRに転送する必要があります。特定の出力ABRへのパケットは、最下部のラベルが出力ABRダウンストリーム割り当てラベルであるMPLSラベルスタックを使用して、入力ABRによってカプセル化されます。
The top label is the P2P RSVP-TE or the MP2P LDP label to reach the egress ABR.
最上位ラベルは、出力ABRに到達するためのP2P RSVP-TEまたはMP2P LDPラベルです。
This section describes the ingress PE/ASBR procedures for constructing segmented inter-area P2MP LSPs.
このセクションでは、セグメント化されたエリア間P2MP LSPを構築するための入力PE / ASBR手順について説明します。
When an ingress PE/ASBR receives a Leaf A-D route and the Route Target Extended Community carried by the route contains the IP address of this PE/ASBR, the following procedures will be executed.
入力PE / ASBRがリーフA-Dルートを受信し、ルートによって運ばれるルートターゲット拡張コミュニティにこのPE / ASBRのIPアドレスが含まれている場合、次の手順が実行されます。
If the value of the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is either 0x01, 0x02, or 0x03, this indicates that the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route (see Section 6.2.2). In this case, the ingress PE/ASBR MUST find an S-PMSI or I-PMSI route whose NLRI has the same value as the Route Key field of the received Leaf A-D route. If such a matching route is found, then the Leaf A-D route MUST be accepted or else it MUST be discarded. If the Leaf A-D route is accepted, then it MUST be processed as per MVPN or VPLS procedures.
受信したリーフADルートのMCAST-VPN NLRIの3番目のオクテットの値が0x01、0x02、または0x03のいずれかである場合、これはリーフADルートがS-PMSIまたはI-PMSI ADルートに応答して発信されたことを示します（セクション6.2.2を参照）。この場合、入力PE / ASBRは、NLRIが受信したリーフA-Dルートのルートキーフィールドと同じ値を持つS-PMSIまたはI-PMSIルートを検出する必要があります。そのような一致するルートが見つかった場合は、リーフA-Dルートを受け入れる必要があります。そうでない場合は、破棄する必要があります。リーフA-Dルートが受け入れられる場合、MVPNまたはVPLS手順に従って処理する必要があります。
If the RD of the received A-D route is set to all zeros or all ones, then the received Leaf A-D route is for the global table multicast service. If this is the first Leaf A-D route for the Route Key carried in the route, the PIM implementation MUST set its upstream (S/RP,G) state machine to Joined state for the (S/RP,G) received via a Leaf A-D route update. Likewise, if this is the withdrawal of the last Leaf A-D route whose Route Key matches a particular (S/RP,G) state, the PIM implementation MUST set its upstream (S/RP,G) state machine to Prune state for the (S/RP,G).
受信されたA-DルートのRDがすべて0またはすべて1に設定されている場合、受信されたリーフA-Dルートはグローバルテーブルマルチキャストサービス用です。これがルートで運ばれるルートキーの最初のリーフADルートである場合、PIM実装はそのアップストリーム（S / RP、G）ステートマシンを、リーフADを介して受信された（S / RP、G）の参加状態に設定する必要がありますルート更新。同様に、これがルートキーが特定の（S / RP、G）状態に一致する最後のリーフADルートの撤回である場合、PIM実装はその（S / RP、G）状態マシンを（ S / RP、G）。
If the value of the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is either 0x01, 0x02, or 0x03 (which indicates that the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route), and P2MP LSP is used as the intra-area LSP in the ingress area, then the procedures for binding the ingress area segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area are the same as in Sections 7 and 7.2.
受信したリーフADルートのMCAST-VPN NLRIの3番目のオクテットの値が0x01、0x02、または0x03の場合（これは、リーフADルートがS-PMSIまたはI-PMSI ADルートに応答して発信されたことを示します） ）、P2MP LSPが入口エリアのエリア内LSPとして使用されている場合、エリア間P2MP LSPの入口エリアセグメントを入口エリアのエリア内P2MP LSPにバインドする手順は、セクション7および7.2。
When the RD of the received Leaf A-D route is all zeros or all ones, as is the case where the inter-area service P2MP LSP is associated with the global table multicast service, the ingress PE MAY originate an S-PMSI A-D route with the RD, multicast source, and multicast group fields being the same as those in the received Leaf A-D route.
エリア間サービスP2MP LSPがグローバルテーブルマルチキャストサービスに関連付けられている場合のように、受信したリーフADルートのRDがすべてゼロまたはすべて1の場合、入力PEは、S-PMSI ADルートをRD、マルチキャストソース、およびマルチキャストグループのフィールドは、受信したリーフADルートのフィールドと同じです。
Further, in the case of global table multicast, an ingress PE MAY originate a wildcard S-PMSI A-D route as per the procedures in [RFC6625] with the RD set to 0. This route may be originated by the ingress PE based on configuration or based on the import of a Leaf A-D route with the RD set to 0. If an ingress PE originates such a route, then the ingress PE MAY decide not to originate (S,G) or (*,G) S-PMSI A-D routes.
さらに、グローバルテーブルマルチキャストの場合、[RFC6625]の手順に従って、RDを0に設定して、入力PEがワイルドカードS-PMSI ADルートを発信してもよい（MAY）。このルートは、構成またはRDが0に設定されたリーフADルートのインポートに基づきます。入力PEがそのようなルートを発信する場合、入力PEは（S、G）または（*、G）S-PMSI ADルートを発信しないことを決定できます（MAY）。 。
The wildcard S-PMSI A-D route MUST carry the Inter-Area P2MP Segmented Next-Hop Extended Community. This Extended Community is constructed following the procedures in Section 4.
ワイルドカードS-PMSI A-Dルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを運ぶ必要があります。この拡張コミュニティは、セクション4の手順に従って構築されます。
It is to be noted that, in the case of global table multicast, if the ingress area uses wildcard S-PMSI, then the backbone area also SHOULD use wildcard S-PMSI for global table multicast, or the ingress ABRs MUST be able to disaggregate traffic carried over the wildcard S-PMSI onto the backbone area (S,G) or (*,G) S-PMSIs. The procedures for such disaggregation require IP processing on the ingress ABRs.
グローバルテーブルマルチキャストの場合、イングレスエリアでワイルドカードS-PMSIを使用する場合、バックボーンエリアでもグローバルテーブルマルチキャストにワイルドカードS-PMSIを使用する必要があります。そうでない場合、イングレスABRは分解できる必要があります。ワイルドカードS-PMSIを介してバックボーンエリア（S、G）または（*、G）S-PMSIに伝送されるトラフィック。このような分解の手順には、入力ABRでのIP処理が必要です。
When ingress replication is used to instantiate the ingress area segment, the Leaf A-D route advertised by the ingress ABR MUST carry a downstream-assigned label in the PMSI Tunnel attribute where the Tunnel Type is set to ingress replication. We will call this the ingress ABR downstream-assigned label. The ingress ABR MUST assign a distinct MPLS label for each Leaf A-D route originated by the ABR.
イングレスエリアセグメントをインスタンス化するためにイングレスレプリケーションが使用される場合、イングレスABRによってアドバタイズされるリーフA-Dルートは、トンネルタイプがイングレスレプリケーションに設定されているPMSIトンネル属性でダウンストリーム割り当てラベルを運ぶ必要があります。これを入力ABRダウンストリーム割り当てラベルと呼びます。入力ABRは、ABRから発信された各リーフA-Dルートに個別のMPLSラベルを割り当てなければなりません（MUST）。
The ingress PE/ASBR MUST forward packets received from the CE, for a particular inter-area P2MP LSP, to all the ingress ABRs from which the ingress PE/ASBR has imported a Leaf A-D route for the inter-area P2MP LSP. A packet to a particular ingress ABR is encapsulated, by the ingress PE/ASBR, using an MPLS label stack the bottom label of which is the ingress ABR downstream-assigned label. The top label is the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR.
入力PE / ASBRは、特定のエリア間P2MP LSPについて、CEから受信したパケットを、エリア間P2MP LSPのリーフA-Dルートをインポートしたすべての入力ABRに転送する必要があります。特定の入力ABRへのパケットは、入力PE / ASBRによって、最下部のラベルが入力ABRダウンストリーム割り当てラベルであるMPLSラベルスタックを使用してカプセル化されます。最上位ラベルは、入力ABRに到達するためのP2P RSVP-TEまたはMP2P LDPラベルです。
For a given inter-area service P2MP LSP, the PE/ASBR that is the root of that LSP controls the type of the intra-area P-tunnel that carries the ingress area segment of that LSP. However, the type of the intra-area P-tunnel that carries the backbone area segment of that LSP may be different from the type of the intra-area P-tunnels that carry the ingress area segment and the egress area segment of that LSP. In that situation, if, for a given inter-area P2MP LSP, it is desirable/necessary to use the same type of tunnel for the intra-area P-tunnels that carry the ingress area segment and for the intra-area P-tunnels that carry the egress area segment of that LSP, then the following procedures on the ingress ABR and egress ABR provide this functionality.
特定のエリア間サービスP2MP LSPの場合、そのLSPのルートであるPE / ASBRは、そのLSPの入力エリアセグメントを伝送するエリア内Pトンネルのタイプを制御します。ただし、そのLSPのバックボーンエリアセグメントを伝送するエリア内Pトンネルのタイプは、そのLSPの入力エリアセグメントと出力エリアセグメントを伝送するエリア内Pトンネルのタイプとは異なる場合があります。その状況で、特定のエリア間P2MP LSPについて、入口エリアセグメントを運ぶエリア内Pトンネルとエリア内Pトンネルに同じタイプのトンネルを使用することが望ましい/必要な場合そのLSPの出力エリアセグメントを伝送する場合、入力ABRおよび出力ABRに関する次の手順がこの機能を提供します。
When an ingress ABR re-advertises into the backbone area a BGP MVPN I-PMSI, S-PMSI A-D route, or VPLS A-D route, the ingress ABR places the PMSI Tunnel attribute of this route into the ATTR_SET BGP attribute [RFC6368], adds this attribute to the re-advertised route, and then replaces the original PMSI Tunnel attribute with a new one (note that the Tunnel Type of the new attribute may be different from the Tunnel Type of the original attribute).
入力ABRがBGP MVPN I-PMSI、S-PMSI ADルート、またはVPLS ADルートをバックボーンエリアに再アドバタイズすると、入力ABRはこのルートのPMSIトンネル属性をATTR_SET BGP属性[RFC6368]に配置し、この属性を再アドバタイズされたルートに追加し、元のPMSIトンネル属性を新しい属性に置き換えます（新しい属性のトンネルタイプは元の属性のトンネルタイプと異なる場合があることに注意してください）。
When an egress ABR re-advertises into the egress area a BGP MVPN I-PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the ATTR_SET BGP attribute [RFC6368], the ABR sets the Tunnel Type of the PMSI Tunnel attribute in the re-advertised route to the Tunnel Type of the PMSI Tunnel attribute carried in the ATTR_SET BGP attribute, and removes the ATTR_SET from the route.
出力ABRがBGP MVPN I-PMSIまたはS-PMSI ADルート、またはVPLS ADルートを出力エリアに再アドバタイズするとき、ルートがATTR_SET BGP属性[RFC6368]を運ぶ場合、ABRはPMSIのトンネルタイプを設定しますATTR_SET BGP属性で伝送されるPMSIトンネル属性のトンネルタイプへの再アドバタイズされたルートのトンネル属性。ルートからATTR_SETを削除します。
As described in the earlier sections, procedures in this document allow the placement of ingress and egress PEs in the backbone area. They also allow the placement of egress PEs in the ingress area or the placement of ingress PEs in the egress area.
前のセクションで説明したように、このドキュメントの手順では、バックボーンエリアに入力および出力PEを配置できます。また、入力エリアに出力PEを配置したり、出力エリアに入力PEを配置したりすることもできます。
For instance, suppose that in the ingress and egress areas, a global table multicast service is being provided, and the data is being sent over PIM-based IP/GRE P-tunnels. Suppose also that it is desired to carry that data over the backbone area through MPLS P-tunnels. This can be done if the ABR connecting the ingress area to the backbone follows the procedures that this document specifies for ingress PEs providing the global table multicast service, and if the ABR connecting the egress area to the backbone follows the procedures that this document specifies for egress PEs providing the global table multicast service.
たとえば、入力エリアと出力エリアでグローバルテーブルマルチキャストサービスが提供されており、データがPIMベースのIP / GRE Pトンネルを介して送信されているとします。また、MPLS Pトンネルを通じてバックボーンエリアを介してそのデータを伝送することが望ましいと仮定します。これは、入力領域をバックボーンに接続するABRが、このドキュメントがグローバルテーブルマルチキャストサービスを提供する入力PEに対して指定する手順に従っている場合、および出力領域をバックボーンに接続するABRがこのドキュメントが指定する手順に従っている場合に実行できます。グローバルテーブルマルチキャストサービスを提供する出力PE。
If MVPN service is being provided in the ingress and egress areas, with the MVPN data carried in PIM-based IP/GRE P-tunnels, this same technique enables the MVPN data to be carried over the backbone in MPLS P-tunnels. The PIM-based IP/GRE P-tunnels in the ingress and egress areas are treated as global table multicasts, and the ABRs provide the ingress and egress PE functionality.
MVPNサービスが入力領域と出力領域で提供され、MVPNデータがPIMベースのIP / GRE Pトンネルで伝送される場合、この同じ手法により、MVPNデータをMPLS Pトンネルのバックボーン上で伝送できます。入力および出力エリアのPIMベースのIP / GRE Pトンネルはグローバルテーブルマルチキャストとして扱われ、ABRは入力および出力PE機能を提供します。
Procedures described in this document could be used in conjunction with the Virtual Hub-and-Spoke procedures [RFC7024].
このドキュメントで説明されている手順は、仮想HUB＆スポーク手順[RFC7024]と組み合わせて使用できます。
This document does not place any restrictions on the placement of Virtual Hubs and Virtual Spokes.
このドキュメントでは、仮想HUBと仮想スポークの配置に制限はありません。
In addition to I-PMSI/S-PMSI A-D routes, the procedures described in this document are applicable to Associated-V-spoke-only I-PMSI A-D routes.
I-PMSI / S-PMSI A-Dルートに加えて、このドキュメントで説明されている手順は、Associated-V-spoke-only I-PMSI A-Dルートに適用できます。
In the scenario where a V-hub, as a result of importing an S-PMSI A-D route in its VRF, originates an S-PMSI A-D route targeted to its V-spokes (as specified in Section 7.8.2 of [RFC7024]), the V-hub SHOULD be able to control via configuration whether the Inter-Area P2MP Segmented Next-Hop Extended Community, if present in the received S-PMSI A-D route, should also be carried in the originated S-PMSI A-D route. By default, if the received S-PMSI A-D route carries the Inter-Area P2MP Segmented Next-Hop Extended Community, then the originated S-PMSI A-D route SHOULD also carry this Extended Community.
VRFにS-PMSI ADルートをインポートした結果としてVハブがVスポークをターゲットとするS-PMSI ADルートを発信するシナリオ（[RFC7024]のセクション7.8.2で指定） 、Vハブは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティが、受信したS-PMSI ADルートに存在する場合、発信されたS-PMSI ADルートでも運ぶ必要があるかどうかを構成を介して制御できる必要があります（SHOULD）。デフォルトでは、受信したS-PMSI A-Dルートがエリア間P2MPセグメント化ネクストホップ拡張コミュニティを運ぶ場合、発信されたS-PMSI A-Dルートもこの拡張コミュニティを運ぶ必要があります。
This section describes the data plane procedures on the ABRs, ingress PEs, egress PEs, and transit routers.
このセクションでは、ABR、入力PE、出力PE、および中継ルーターのデータプレーン手順について説明します。
When procedures in this document are followed to signal inter-area P2MP segmented LSPs, ABRs are required to perform only MPLS switching. When an ABR receives an MPLS packet from an "incoming" intra-area segment of the inter-area P2MP segmented LSP, it forwards the packet, based on MPLS switching, on to another "outgoing" intra-area segment of the inter-area P2MP segmented LSP.
このドキュメントの手順に従ってエリア間P2MPセグメント化LSPをシグナリングする場合、ABRはMPLSスイッチングのみを実行する必要があります。 ABRは、エリア間P2MPセグメントLSPの「着信」エリア内セグメントからMPLSパケットを受信すると、MPLSスイッチングに基づいて、エリア間の他の「発信」エリア内セグメントにパケットを転送します。 P2MPセグメント化LSP。
If the outgoing intra-area segment is instantiated using a P2MP LSP, and if there is a one-to-one mapping between the outgoing intra-area segment and the P2MP LSP, then the ABR MUST pop the incoming segment's label stack and push the label stack of the outgoing P2MP LSP. If there is a many-to-one mapping between outgoing intra-area segments and the P2MP LSP, then the ABR MUST pop the incoming segment's label stack and first push the upstream-assigned label corresponding to the outgoing intra-area segment, if such a label has been assigned, and then push the label stack of the outgoing P2MP LSP.
発信エリア内セグメントがP2MP LSPを使用してインスタンス化され、発信エリア内セグメントとP2MP LSPの間に1対1のマッピングがある場合、ABRは着信セグメントのラベルスタックをポップし、発信P2MP LSPのラベルスタック。発信エリア内セグメントとP2MP LSPの間に多対1のマッピングがある場合、ABRは着信セグメントのラベルスタックをポップし、発信エリア内セグメントに対応する上流割り当てラベルを最初にプッシュする必要があります（該当する場合）。ラベルが割り当てられ、発信P2MP LSPのラベルスタックをプッシュします。
If the outgoing intra-area segment is instantiated using ingress replication, then the ABR must pop the incoming segment's label stack and replicate the packet once to each leaf ABR or PE of the outgoing intra-area segment. The label stack of the packet sent to each such leaf MUST first include a downstream-assigned label assigned by the leaf to the segment, followed by the label stack of the P2P or MP2P LSP to the leaf.
入力レプリケーションを使用して発信エリア内セグメントがインスタンス化される場合、ABRは着信セグメントのラベルスタックをポップし、パケットを発信エリア内セグメントの各リーフABRまたはPEに1回複製する必要があります。そのような各リーフに送信されるパケットのラベルスタックは、最初にリーフによってセグメントに割り当てられたダウンストリーム割り当てラベルを含み、その後にP2PまたはMP2P LSPのラベルスタックをリーフに含める必要があります。
An egress PE must first identify the inter-area P2MP segmented LSP based on the incoming label stack. After this identification, the egress PE must forward the packet using the application that is bound to the inter-area P2MP segmented LSP.
出力PEはまず、着信ラベルスタックに基づいてエリア間P2MPセグメント化LSPを識別する必要があります。この識別の後、出力PEは、エリア間P2MPセグメント化LSPにバインドされているアプリケーションを使用してパケットを転送する必要があります。
Note that the application-specific forwarding for MVPN service may require the egress PE to determine whether the packets were received from the expected sender PE. When the application is MVPN, the FEC of an inter-area P2MP segmented LSP is at the granularity of the sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D routes both carry the Originating Router's IP Address. Thus, an egress PE could associate the data arriving on P-tunnels advertised by these routes with the Originating Router's IP Address carried by these routes, which is the same as the ingress PE. Since a unique label stack is associated with each such FEC, the egress PE can determine the sender PE from the label stack.
MVPNサービスのアプリケーション固有の転送では、パケットが予期された送信側PEから受信されたかどうかを判断するために出力PEが必要になる場合があることに注意してください。アプリケーションがMVPNの場合、エリア間P2MPセグメント化LSPのFECは、送信側PEの細分性です。 MVPNイントラAS I-PMSI A-DルートとS-PMSI A-Dルートの両方が発信元ルーターのIPアドレスを運ぶことに注意してください。したがって、出力PEは、これらのルートによってアドバタイズされたPトンネルに到着するデータを、これらのルートによって伝送される発信元ルーターのIPアドレスに関連付けることができます。これは、入力PEと同じです。このような各FECには一意のラベルスタックが関連付けられているため、出力PEはラベルスタックから送信側PEを判別できます。
Likewise for VPLS service, for the purposes of Media Access Control (MAC) learning the egress, the PE must be able to determine the "VE-ID" (VPLS Edge Device Identifier) from which the packets have been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus, an egress PE could associate the data arriving on P-tunnels advertised by these routes with the VE-ID carried by these routes. Since a unique label stack is associated with each such FEC, the egress PE can perform MAC learning for packets received from a given VE-ID.
同様に、VPLSサービスの場合、出力を学習するメディアアクセスコントロール（MAC）の目的で、PEはパケットの受信元である「VE-ID」（VPLSエッジデバイス識別子）を判別できる必要があります。 VPLS A-DルートのFECはVE-IDを伝送します。したがって、出力PEは、これらのルートによってアドバタイズされたPトンネルに到着するデータを、これらのルートによって運ばれるVE-IDに関連付けることができます。このような各FECには一意のラベルスタックが関連付けられているため、出力PEは、特定のVE-IDから受信したパケットに対してMAC学習を実行できます。
When the application is global table multicast, it is sufficient for the label stack to include identification of the sender upstream node. When P2MP LSPs are used, this requires that PHP MUST be turned off. When ingress replication is used, the egress PE knows the incoming downstream-assigned label to which it has bound a particular (S/*,G) and must accept packets with only that label for that (S/*,G).
アプリケーションがグローバルテーブルマルチキャストの場合、ラベルスタックには送信者の上流ノードの識別情報が含まれていれば十分です。 P2MP LSPを使用する場合は、PHPをオフにする必要があります。入力レプリケーションが使用される場合、出力PEは特定の（S / *、G）をバインドした着信ダウンストリーム割り当てラベルを認識し、その（S / *、G）のラベルのみを持つパケットを受け入れる必要があります。
An Ingress PE must perform application-specific forwarding procedures to identify the outgoing intra-area segment of an incoming packet.
入力PEは、アプリケーション固有の転送手順を実行して、着信パケットの発信エリア内セグメントを識別する必要があります。
If the outgoing intra-area segment is instantiated using a P2MP LSP, and if there is a one-to-one mapping between the outgoing intra-area segment and the P2MP LSP, then the ingress PE MUST encapsulate the packet in the label stack of the outgoing P2MP LSP. If there is a many-to-one mapping between outgoing intra-area segments and the P2MP LSP, then the PE MUST first push the upstream-assigned label corresponding to the outgoing intra-area segment, if such a label has been assigned, and then push the label stack of the outgoing P2MP LSP.
発信エリア内セグメントがP2MP LSPを使用してインスタンス化され、発信エリア内セグメントとP2MP LSPの間に1対1のマッピングがある場合、入力PEはパケットを次のラベルスタックにカプセル化する必要があります。発信P2MP LSP。発信エリア内セグメントとP2MP LSPの間に多対1のマッピングがある場合、PEはまず、そのようなラベルが割り当てられている場合、発信エリア内セグメントに対応する上流割り当てラベルをプッシュする必要があります。次に、発信P2MP LSPのラベルスタックをプッシュします。
If the outgoing intra-area segment is instantiated using ingress replication, then the PE must replicate the packet once to each leaf ABR or PE of the outgoing intra-area segment. The label stack of the packet sent to each such leaf MUST first include a downstream-assigned label assigned by the leaf to the segment, followed by the label stack of the P2P or MP2P LSP to the leaf.
発信エリア内セグメントが入力レプリケーションを使用してインスタンス化される場合、PEは発信エリア内セグメントの各リーフABRまたはPEにパケットを1回複製する必要があります。そのような各リーフに送信されるパケットのラベルスタックは、最初にリーフによってセグメントに割り当てられたダウンストリーム割り当てラベルを含み、その後にP2PまたはMP2P LSPのラベルスタックをリーフに含める必要があります。
When procedures in this document are followed to signal inter-area P2MP segmented LSPs, transit routers in each area perform only MPLS switching.
このドキュメントの手順に従ってエリア間P2MPセグメント化LSPをシグナリングする場合、各エリアの中継ルータはMPLSスイッチングのみを実行します。
This section describes OPTIONAL procedures that allow multiple (inter-area) P2MP LSPs to be aggregated into a single inter-area P2MP "transport LSP". The segmentation procedures, as specified in this document, are then applied to these inter-area P2MP transport LSPs, rather than being applied directly to the individual LSPs that are aggregated into the transport. In the following, the individual LSPs that are aggregated into a single transport LSP will be known as "service LSPs".
このセクションでは、複数の（エリア間）P2MP LSPを単一のエリア間P2MP「トランスポートLSP」に集約できるようにするオプションの手順について説明します。このドキュメントで指定されているセグメンテーション手順は、トランスポートに集約される個々のLSPに直接適用されるのではなく、これらのエリア間P2MPトランスポートLSPに適用されます。以下では、単一のトランスポートLSPに集約される個々のLSPを「サービスLSP」と呼びます。
For the PMSI Tunnel attribute, we define a new Tunnel Type, called "Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE Address, Local Number>. This Tunnel Type is assigned a value of 8. The Source PE Address is the address of the PE that originates the (service) A-D route that carries this attribute, and the Local Number is a number that is unique to the Source PE. The length of the Local Number part is the same as the length of the Source PE Address.
PMSIトンネル属性の場合、「トランスポートトンネル」と呼ばれる新しいトンネルタイプを定義します。そのトンネルIDは、タプル<Source PE Address、Local Number>です。このトンネルタイプには値8が割り当てられます。ソースPEアドレスは、この属性を運ぶ（サービス）A-Dルートを発信するPEのアドレスであり、ローカル番号は、ソースPEに一意の番号です。ローカル番号部分の長さは、ソースPEアドレスの長さと同じです。
Thus, if the Source PE Address is an IPv4 address, then the Local Number part is 4 octets; if the Source PE Address is an IPv6 address, then the Local Number part is 16 octets.
したがって、ソースPEアドレスがIPv4アドレスの場合、ローカル番号の部分は4オクテットです。ソースPEアドレスがIPv6アドレスの場合、ローカル番号の部分は16オクテットです。
When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, determining the leaf nodes of the LSPs being aggregated is essential for being able to trade-off the overhead due to the P2MP LSPs versus suboptimal use of bandwidth due to the partial congruency of the LSPs being aggregated.
P2MP LSP階層を使用して複数のP2MP LSPを集約する場合、集約されているLSPのリーフノードを特定することは、集約されているLSPの部分的な合同による帯域幅の最適以下の使用とP2MP LSPによるオーバーヘッドをトレードオフできるために不可欠です。 。
Therefore, if a PE that is a root of a given service P2MP LSP wants to aggregate this LSP with other (service) P2MP LSPs rooted at the same PE into an inter-area P2MP transport LSP, the PE should first determine all the leaf nodes of that service LSP, as well as those of the other service LSPs being aggregated.
したがって、特定のサービスのルートであるPE P2MP LSPが、このLSPを同じPEをルートとする他の（サービス）P2MP LSPと一緒にエリア間P2MPトランスポートLSPに集約する場合、PEは最初にすべてのリーフノードを決定する必要があります。そのサービスLSP、および集約されている他のサービスLSPのサービス
To accomplish this, the PE sets the PMSI Tunnel attribute of the service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS service) associated with that LSP as follows. The Tunnel Type is set to "No tunnel information present", and the "Leaf Information Required" flag is set to 1. The route MUST NOT carry the Inter-Area P2MP Segmented Next-Hop Extended Community. In contrast to the procedures for the MVPN and VPLS A-D routes described so far, the Route Reflectors that participate in the distribution of this route need not be ABRs.
これを実現するために、PEは、次のように、そのLSPに関連付けられているサービスA-Dルート（MVPNまたはVPLSサービスのI-PMSIまたはS-PMSI A-Dルート）のPMSIトンネル属性を設定します。 Tunnel Typeは「No tunnel information present」に設定され、「Leaf Information Required」フラグは1に設定されます。ルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送してはなりません。これまでに説明したMVPNおよびVPLS A-Dルートの手順とは対照的に、このルートの配布に参加するルートリフレクターはABRである必要はありません。
Once the ingress PE determines all the leaves of a given P2MP service LSP, the PE (using some local criteria) selects a particular inter-area transport P2MP LSP to be used for carrying the (inter-area) service P2MP LSP.
入力PEが特定のP2MPサービスLSPのすべてのリーフを決定すると、（ローカル基準を使用して）PEは、（エリア間）サービスP2MP LSPの伝送に使用される特定のエリア間トランスポートP2MP LSPを選択します。
Once the PE selects the transport P2MP LSP, the PE (re-)originates the service A-D route. The PMSI Tunnel attribute of this route now carries the Tunnel Identifier of the selected transport LSP, with the Tunnel Type set to "Transport Tunnel". If the transport LSP carries multiple P2MP service LSPs, then the MPLS Label field in the attribute carries an upstream-assigned label assigned by the PE that is bound to the P2MP FEC of the inter-area P2MP service LSP. Otherwise, this field is set to Implicit NULL.
PEがトランスポートP2MP LSPを選択すると、PEはサービスのA-Dルートを（再）発信します。このルートのPMSIトンネル属性には、選択されたトランスポートLSPのトンネル識別子が含まれ、トンネルタイプは「トランスポートトンネル」に設定されています。トランスポートLSPが複数のP2MPサービスLSPを伝送する場合、属性のMPLSラベルフィールドは、エリア間P2MPサービスLSPのP2MP FECにバインドされたPEによって割り当てられたアップストリーム割り当てラベルを伝送します。それ以外の場合、このフィールドは暗黙的NULLに設定されます。
As described earlier, this service A-D route MUST NOT carry the Inter-Area P2MP Segmented Next-Hop Extended Community, and the Route Reflectors that participate in the distribution of this route need not be ABRs.
前述のように、このサービスA-Dルートは、エリア間P2MPセグメント化ネクストホップ拡張コミュニティを伝送してはならず（MUST）、このルートの配布に参加するルートリフレクターはABRである必要はありません。
When an egress PE receives and accepts an MVPN or VPLS service A-D route, if the "Leaf Information Required" flag in the PMSI Tunnel attribute of the received A-D route is set to 1, and the route does not carry the Inter-Area P2MP Segmented Next-Hop Extended Community, then the egress PE, following the "regular" MVPN or VPLS procedures associated with the received A-D route (as specified in [RFC6514] and [RFC7117]), originates a Leaf A-D route.
出力PEがMVPNまたはVPLSサービスのADルートを受信して受け入れるとき、受信したADルートのPMSIトンネル属性の「Leaf Information Required」フラグが1に設定されていて、ルートがエリア間P2MPセグメント化されていないネクストホップ拡張コミュニティ、次に出力PEは、（[RFC6514]および[RFC7117]で指定された）受信したADルートに関連付けられた「通常の」MVPNまたはVPLS手順に従って、リーフADルートを発信します。
In addition, if the Tunnel Type in the PMSI Tunnel attribute of the received service A-D route is set to "Transport Tunnel", the egress PE originates yet another Leaf A-D route.
さらに、受信したサービスA-DルートのPMSIトンネル属性のトンネルタイプが「トランスポートトンネル」に設定されている場合、出力PEはさらに別のリーフA-Dルートを発信します。
The format of the Route Key field of the MCAST-VPN NLRI of this additional Leaf A-D route is the same as defined in Section 6.2.2. The Route Key field of the MCAST-VPN NLRI of this route is constructed as follows:
この追加のリーフA-DルートのMCAST-VPN NLRIのルートキーフィールドの形式は、セクション6.2.2で定義されているものと同じです。このルートのMCAST-VPN NLRIのルートキーフィールドは、次のように構成されます。
RD (8 octets) - set to 0
RD（8オクテット）-0に設定
Multicast Source Length, Multicast Source - constructed from the Source PE Address part of the Tunnel Identifier carried in the PMSI Tunnel attribute of the received service S-PMSI A-D route.
マルチキャストソースの長さ、マルチキャストソース-受信したサービスS-PMSI A-DルートのPMSIトンネル属性で伝送されるトンネル識別子のソースPEアドレス部分から構築されます。
Multicast Group Length, Multicast Group - constructed from the Local Number part of the Tunnel Identifier carried in the PMSI Tunnel attribute of the received service S-PMSI A-D route.
マルチキャストグループの長さ、マルチキャストグループ-受信したサービスS-PMSI A-DルートのPMSIトンネル属性に含まれるトンネル識別子のローカル番号部分から構築されます。
Ingress PE IP Address - set to the Source PE Address part of the Tunnel Identifier carried in the PMSI Tunnel attribute of the received service S-PMSI A-D route.
入力PE IPアドレス-受信したサービスS-PMSI A-DルートのPMSIトンネル属性で伝送されるトンネル識別子のソースPEアドレス部分に設定されます。
The egress PE, when determining the upstream ABR, follows the procedures specified in Section 6.1 for global table multicast.
出力PEは、アップストリームABRを決定するときに、グローバルテーブルマルチキャストについてセクション6.1で指定された手順に従います。
The egress PE constructs the rest of the Leaf A-D route following the procedures specified in Section 6.2.3.
出力PEは、セクション6.2.3で指定された手順に従って、リーフA-Dルートの残りを構築します。
From that point on we follow the procedures used for the Leaf A-D routes for global table multicast, as outlined below.
その時点から、以下に概説するように、グローバルテーブルマルチキャストのリーフA-Dルートに使用される手順に従います。
In this section, we specify ingress and egress ABRs, as well as ingress PE procedures for P2MP transport LSPs.
このセクションでは、入力ABRと出力ABR、およびP2MPトランスポートLSPの入力PE手順を指定します。
When an egress ABR receives the Leaf A-D route, and P2MP LSP is used to instantiate the egress area segment of the inter-area transport LSP, the egress ABR will advertise into the egress area an S-PMSI A-D route. This route is constructed following the procedures in Section 7.2.2.1. The egress PE(s) will import this route.
出力ABRがリーフA-Dルートを受信し、P2MP LSPを使用してエリア間トランスポートLSPの出力エリアセグメントをインスタンス化すると、出力ABRは出力エリアにS-PMSI A-Dルートをアドバタイズします。このルートは、7.2.2.1項の手順に従って作成されます。出力PEはこのルートをインポートします。
The egress ABR will also propagate, with appropriate modifications, the received Leaf A-D route into the backbone area. This is irrespective of whether the egress area segment is instantiated using P2MP LSP or ingress replication.
出力ABRも、適切な変更を加えて、受信したリーフA-Dルートをバックボーンエリアに伝搬します。これは、出力エリアセグメントがP2MP LSPまたは入力レプリケーションを使用してインスタンス化されているかどうかには関係ありません。
If P2MP LSP is used to instantiate the backbone area segment of the inter-area transport LSP, then an ingress ABR will advertise into the backbone area an S-PMSI A-D route. This route is constructed following the procedures in Section 7.1.2.1. The egress ABR(s) will import this route.
P2MP LSPを使用してエリア間トランスポートLSPのバックボーンエリアセグメントをインスタンス化する場合、入力ABRはS-PMSI A-Dルートをバックボーンエリアにアドバタイズします。このルートは、7.1.2.1項の手順に従って作成されます。出力ABRはこのルートをインポートします。
The ingress ABR will also propagate, with appropriate modifications, the received Leaf A-D route into the ingress area towards the ingress/root PE. This is irrespective of whether the backbone area segment is instantiated using P2MP LSP or ingress replication.
入力ABRは、適切な変更を加えて、受信したリーフA-Dルートを入力/ルートPEに向けて入力エリアに伝搬します。これは、バックボーンエリアセグメントがP2MP LSPまたは入力レプリケーションを使用してインスタンス化されているかどうかには関係ありません。
Finally, if P2MP LSP is used to instantiate the ingress area segment, the ingress PE will advertise into the ingress area an S-PMSI A-D route with the RD, multicast source, and multicast group fields being the same as those in the received Leaf A-D route. The PMSI Tunnel attribute of this route contains the identity of the intra-area P2MP LSP used to instantiate the ingress area segment, and an upstream-assigned MPLS label. The ingress ABR(s) and other PE(s) in the ingress area, if any, will import this route. The ingress PE will use the (intra-area) P2MP LSP advertised in this route for carrying traffic associated with the original service A-D route advertised by the PE.
最後に、P2MP LSPを使用して入力エリアセグメントをインスタンス化する場合、入力PEは、RD、マルチキャストソース、およびマルチキャストグループフィールドが受信したリーフADと同じであるS-PMSI ADルートを入力エリアにアドバタイズします。ルート。このルートのPMSIトンネル属性には、入力エリアセグメントのインスタンス化に使用されるエリア内P2MP LSPのID、およびアップストリームに割り当てられたMPLSラベルが含まれています。イングレスエリア内のイングレスABRおよびその他のPEがある場合は、このルートをインポートします。入力PEは、このルートでアドバタイズされた（エリア内）P2MP LSPを使用して、PEによってアドバタイズされた元のサービスA-Dルートに関連付けられたトラフィックを伝送します。
Use of inter-area transport P2MP LSPs, as described in this section, creates a level of indirection between (inter-area) P2MP service LSPs, and intra-area transport LSPs that carry the service LSPs. Rather than segmenting (inter-area) service P2MP LSPs, and then aggregating (intra-area) segments of these service LSPs into intra-area transport LSPs, this approach first aggregates multiple (inter-area) service P2MP LSPs into a single inter-area transport P2MP LSP, then segments such inter-area transport P2MP LSPs, and then aggregates (intra-area) segments of these inter-area transport LSPs into intra-area transport LSPs.
このセクションで説明するように、エリア間トランスポートP2MP LSPを使用すると、（エリア間）P2MPサービスLSPと、サービスLSPを運ぶエリア内トランスポートLSPの間に一定レベルの間接参照が作成されます。このアプローチでは、（エリア間）サービスP2MP LSPをセグメント化してから、これらのサービスLSPの（エリア内）セグメントをエリア内トランスポートLSPに集約するのではなく、まず複数の（エリア間）サービスP2MP LSPを単一のインターエリアLSPに集約します。エリアトランスポートP2MP LSP、次にそのようなエリア間トランスポートP2MP LSPをセグメント化し、これらのエリア間トランスポートLSPの（エリア内）セグメントをエリア内トランスポートLSPに集約します。
On one hand, this approach could result in reducing the state (and the overhead associated with maintaining the state) on ABRs. This is because instead of requiring ABRs to maintain state for individual P2MP service LSPs, ABRs would need to maintain state only for the inter-area P2MP transport LSPs. Note, however, that this reduction is possible only if a single inter-area P2MP transport LSP aggregates more than one (inter-area) service LSP. In the absence of such aggregation, use of inter-area transport LSPs provides no benefits, yet results in extra overhead. And while such aggregation does allow reduced state on ABRs, it comes at a price, as described below.
一方では、このアプローチにより、ABRの状態（および状態の維持に関連するオーバーヘッド）を減らすことができます。これは、ABRが個々のP2MPサービスLSPの状態を維持することを要求する代わりに、エリア間P2MPトランスポートLSPについてのみ状態を維持する必要があるためです。ただし、この削減は、単一のエリア間P2MPトランスポートLSPが複数の（エリア間）サービスLSPを集約する場合にのみ可能であることに注意してください。そのような集約がない場合、エリア間トランスポートLSPを使用してもメリットはありませんが、余分なオーバーヘッドが発生します。また、そのような集約ではABRの状態を削減できますが、以下に説明するように、代償が伴います。
As we mentioned before, aggregating multiple P2MP service LSPs into a single inter-area P2MP transport LSP requires the PE rooted at these LSPs to determine all the leaf nodes of the service LSPs to be aggregated. This means that the root PE has to track all the leaf PEs of these LSPs. In contrast, when one applies segmentation procedures directly to the P2MP service LSPs, the root PE has to track only the leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an ingress ABR has to track only the egress ABRs. Finally, an egress ABR has to track only the leaf PEs in its own area. Therefore, while the total overhead of leaf tracking due to the P2MP service LSPs is about the same in both approaches, the distribution of this overhead is different. Specifically, when one uses inter-area P2MP transport LSPs, this overhead is concentrated on the ingress PE. When one applies segmentation procedures directly to the P2MP service LSPs, this overhead is distributed among the ingress PE and ABRs.
前述したように、複数のP2MPサービスLSPを単一のエリア間P2MPトランスポートLSPに集約するには、集約するサービスLSPのすべてのリーフノードを決定するために、これらのLSPをルートとするPEが必要です。つまり、ルートPEはこれらのLSPのすべてのリーフPEを追跡する必要があります。対照的に、セグメンテーション手順をP2MPサービスLSPに直接適用する場合、ルートPEは、自身のIGPエリア内のリーフPEと入力ABRのみを追跡する必要があります。同様に、入力ABRは出力ABRのみを追跡する必要があります。最後に、出力ABRは、自身のエリア内のリーフPEのみを追跡する必要があります。したがって、P2MPサービスLSPによるリーフトラッキングの合計オーバーヘッドはどちらのアプローチでもほぼ同じですが、このオーバーヘッドの配分は異なります。特に、エリア間P2MPトランスポートLSPを使用する場合、このオーバーヘッドは入力PEに集中します。セグメンテーション手順をP2MPサービスLSPに直接適用すると、このオーバーヘッドは入力PEとABRに分散されます。
Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to bear the overhead of leaf tracking for inter-area P2MP transport LSPs. In contrast, when one applies segmentation procedures directly to the P2MP service LSPs, there is no such overhead (as there are no inter-area P2MP transport LSPs).
さらに、エリア間P2MPトランスポートLSPを使用する場合、ABRはエリア間P2MPトランスポートLSPのリーフトラッキングのオーバーヘッドを負担する必要があります。対照的に、セグメンテーション手順をP2MPサービスLSPに直接適用する場合、そのようなオーバーヘッドはありません（エリア間P2MPトランスポートLSPがないため）。
Use of inter-area P2MP transport LSPs may also result in more bandwidth inefficiency, as compared to applying segmentation procedures directly to the P2MP service LSPs. This is because with inter-area P2MP transport LSPs the ABRs aggregate segments of inter-area P2MP transport LSPs, rather than segments of (inter-area) P2MP service LSPs. To illustrate this, consider the following example.
エリア間P2MPトランスポートLSPを使用すると、セグメンテーション手順をP2MPサービスLSPに直接適用する場合と比較して、帯域幅が非効率になる可能性があります。これは、エリア間P2MPトランスポートLSPでは、ABRが（エリア間）P2MPサービスLSPのセグメントではなく、エリア間P2MPトランスポートLSPのセグメントを集約するためです。これを説明するために、次の例を考えます。
Assume PE1 in Area 1 is an ingress PE, with two multicast streams, (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with receivers for both (C-S1, C-G1) and (C-S2, C-G2). Finally, assume that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2).
エリア1のPE1は、2つのマルチキャストストリーム（C-S1、C-G1）と（C-S2、C-G2）を持つ入力PEであり、PE1に接続されたMVPNサイトによって発信されたと仮定します。エリア2のPE2には（C-S1、C-G1）のレシーバーがあるMVPNサイトがあり、エリア3のPE3とPE4には（C-S1、C-G1）と（C- S2、C-G2）。最後に、エリア4のPE5に、（C-S2、C-G2）のレシーバーがあるMVPNサイトがあると想定します。
When segmentation applies directly to the P2MP service LSPs, Area 2 would have just one intra-area transport LSP that would carry the egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3 would have just one intra-area transport LSP that would carry the egress area segments of both the P2MP service LSP for (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one intra-area transport LSP that would carry the egress area segment of the P2MP service LSP for (C-S2, C-G2). Note that there is no bandwidth inefficiency in this case at all.
セグメンテーションがP2MPサービスLSPに直接適用される場合、エリア2には、（C-S1、C-G1）のP2MPサービスLSPの出力エリアセグメントを運ぶエリア内トランスポートLSPが1つだけあります。エリア3には、（C-S1、C-G1）のP2MPサービスLSPと（C-S2、C-G2）のP2MPサービスLSPの両方の出力エリアセグメントを運ぶエリア内トランスポートLSPが1つだけあります。エリア4には、（C-S2、C-G2）のP2MPサービスLSPの出力エリアセグメントを伝送するエリア内トランスポートLSPが1つだけあります。この場合、帯域幅の非効率性はまったくないことに注意してください。
When using inter-area P2MP transport LSPs, to achieve the same state overhead on the routers within each of the egress areas (except for egress ABRs), PE1 would need to aggregate the P2MP service LSP for (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same inter-area P2MP transport LSP. While such aggregation would reduce state on ABRs, it would also result in bandwidth inefficiency, as (C-S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also to PE5, which has no receivers for this stream. Likewise, (C-S2, C-G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, which has no receivers for this stream.
エリア間P2MPトランスポートLSPを使用する場合、各出力エリア（出力ABRを除く）内のルーターで同じ状態オーバーヘッドを実現するには、PE1は（C-S1、C-G1）のP2MPサービスLSPを集約する必要があります。 （C-S2、C-G2）のP2MPサービスLSPを同じエリア間P2MPトランスポートLSPに送ります。 （C-S1、C-G1）は、PE2、PE3、およびPE4だけでなく、PE5にも配信されるため、ABRの状態を削減する一方で、ABRの状態を削減しますが、レシーバーがないPE5にも配信されますこのストリーム。同様に、（C-S2、C-G2）は、PE3、PE4、PE5だけでなく、このストリームのレシーバーがないPE2にも配信されます。
This document defines a new BGP Extended Community called "Inter-Area P2MP Segmented Next-Hop" (see Section 4). This may be either a Transitive IPv4-Address-Specific Extended Community or a Transitive IPv6-Address-Specific Extended Community. IANA has assigned the value 0x12 in the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry, and IANA has assigned the value 0x0012 in the "Transitive IPv6-Address-Specific Extended Community Types" registry. This document is the reference for both code points.
このドキュメントでは、「エリア間P2MPセグメント化ネクストホップ」と呼ばれる新しいBGP拡張コミュニティを定義しています（セクション4を参照）。これは、推移的なIPv4-Address-Specific Extended Communityまたは推移的なIPv6-Address-Specific Extended Communityのいずれかです。 IANAは「Transitive IPv4-Address-Specific Extended Community Sub-Types」レジストリで値0x12を割り当て、IANAは「Transitive IPv6-Address-Specific Extended Community Type」レジストリで値0x0012を割り当てました。このドキュメントは、両方のコードポイントのリファレンスです。
IANA has assigned the value 0x08 in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry [RFC7385] as "Transport Tunnel" (see Section 14).
IANAは、「P-Multicast Service Interface Tunnel（PMSI Tunnel）Tunnel Types」レジストリ[RFC7385]で値0x08を「Transport Tunnel」として割り当てました（セクション14を参照）。
This document makes use of a Route Distinguisher whose value is all ones. The two-octet type field of this Route Distinguisher thus has the value 65535. IANA has assigned this value in the "Route Distinguisher Type Field" registry as "For Use Only in Certain Leaf A-D Routes", with this document as the reference.
このドキュメントでは、値がすべて1のルート識別子を使用しています。したがって、このRoute Distinguisherの2オクテットタイプフィールドの値は65535です。IANAは、「Route Distinguisher Type Field」レジストリでこの値を「特定のリーフA-Dルートでのみ使用」として割り当て、このドキュメントを参照しました。
Procedures described in this document are subject to security threats similar to those experienced by any MPLS deployment. It is recommended that baseline security measures are considered as described in "Security Framework for MPLS and GMPLS Networks"
このドキュメントで説明されている手順は、MPLS展開で発生するものと同様のセキュリティ上の脅威の影響を受けます。 「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」で説明されているように、ベースラインのセキュリティ対策を検討することをお勧めします。
[RFC5920], in the mLDP specification [RFC6388], and in the P2MP RSVP-TE specification [RFC3209]. The security considerations of [RFC6513] are also applicable.
[RFC5920]、mLDP仕様[RFC6388]、およびP2MP RSVP-TE仕様[RFC3209]。 [RFC6513]のセキュリティに関する考慮事項も適用されます。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、DOI 10.17487 / RFC1997、August 1996、<http://www.rfc-editor.org/info/ rfc1997>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<http://www.rfc-editor.org/info / rfc4360>。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.
[RFC4456]ベイツ、T。、チェン、E。、およびR.チャンドラ、「BGP Route Reflection：An Alternative to Full Mesh Internal BGP（IBGP）」、RFC 4456、DOI 10.17487 / RFC4456、2006年4月、<http：/ /www.rfc-editor.org/info/rfc4456>。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、DOI 10.17487 / RFC4684、2006年11月、<http://www.rfc-editor.org/info/rfc4684>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<http：// www。 rfc-editor.org/info/rfc4760>。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service（VPLS）Using BGP for Auto-Discovery and Signaling"、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<http ：//www.rfc-editor.org/info/rfc4761>。
[RFC4875] 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, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] 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パス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<http：//www.rfc -editor.org/info/rfc5331>。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <http://www.rfc-editor.org/info/rfc5332>.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、DOI 10.17487 / RFC5332、2008年8月、<http：// www。 rfc-editor.org/info/rfc5332>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、DOI 10.17487 / RFC6074 、2011年1月、<http://www.rfc-editor.org/info/rfc6074>。
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.
[RFC6368] Marques、P.、Raszuk、R.、Patel、K.、Kumaki、K。、およびT. Yamagata、「BGP / MPLS IP仮想プライベートネットワーク（VPN）のプロバイダー/カスタマーエッジプロトコルとしての内部BGP」 、RFC 6368、DOI 10.17487 / RFC6368、2011年9月、<http://www.rfc-editor.org/info/rfc6368>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、DOI 10.17487 / RFC6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、DOI 10.17487 / RFC6513、February 2012、<http：//www.rfc-editor .org / info / rfc6513>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< http://www.rfc-editor.org/info/rfc6514>。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャストVPNオートディスカバリルートのワイルドカード」、RFC 6625、DOI 10.17487 / RFC6625、2012年5月、<http://www.rfc-editor.org/info/rfc6625>。
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.
[RFC7117] Aggarwal、R.、Ed。、Kamite、Y.、Fang、L.、Rekhter、Y。、およびC. Kodeboniya、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、DOI 10.17487 / RFC7117 、2014年2月、<http://www.rfc-editor.org/info/rfc7117>。
[RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <http://www.rfc-editor.org/info/rfc7385>.
[RFC7385] Andersson、L。およびG. Swallow、「I-ANA Registry for P-Multicast Service Interface（PMSI）Tunnel Type Code Points」、RFC 7385、DOI 10.17487 / RFC7385、2014年10月、<http：//www.rfc- editor.org/info/rfc7385>。
[GTM] Zhang, J, Giuliano, L, Rosen, E., Ed., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-mvpn-global-table-mcast-00, November 2014.
[GTM] Zhang、J、Giuliano、L、Rosen、E.、Ed。、Subramanian、K.、Pacella、D.、J。Schiller、「BGP-MVPNプロシージャを使用したグローバルテーブルマルチキャスト」、作業中、ドラフト-ietf-bess-mvpn-global-table-mcast-00、2014年11月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, <http://www.rfc-editor.org/info/rfc7024>.
[RFC7024] Jeng、H.、Uttaro、J.、Jalil、L.、Decraene、B.、Rekhter、Y。、およびR. Aggarwal、「BGP / MPLS VPNの仮想ハブアンドスポーク」、RFC 7024、 DOI 10.17487 / RFC7024、2013年10月、<http://www.rfc-editor.org/info/rfc7024>。
[SEAMLESS-MPLS] Leymann, N., Ed., Decraene, B., Filsfils, C., Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.
[シームレス-MPLS] Leymann、N.、Ed。、Decraene、B.、Filsfils、C.、Konstantynowicz、M.、Ed。、and D. Steinberg、 "Seamless MPLS Architecture"、Work in Progress、draft-ietf- mpls-seamless-mpls-07、2014年6月。
Acknowledgements
謝辞
We would like to thank Loa Andersson and Qin Wu for their review and comments.
Loa AnderssonとQin Wuのレビューとコメントに感謝します。
Authors' Addresses
著者のアドレス
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 United States
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Eric C Rosen Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States EMail: erosen@juniper.net
エリックCローゼンジュニパーネットワークス10テクノロジーパークドライブウェストフォード、マサチューセッツ01886米国Eメール：erosen@juniper.net
Rahul Aggarwal EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Eメール：raggarwa_1@yahoo.com
Thomas Morin Orange 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@orange.com
Thomas Morin Orange 2、avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：thomas.morin@orange.com
Irene Grosclaude Orange 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: irene.grosclaude@orange.com
Irene Grosclaude Orange 2、avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：irene.grosclaude@orange.com
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 Germany EMail: n.leymann@telekom.de
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21ベルリン10781ドイツEメール：n.leymann@telekom.de
Samir Saad AT&T EMail: samirsaad1@outlook.com
Samir Sad at＆iメール：Summersad1@outlook.com