[要約] RFC 7117は、VPLSにおけるマルチキャストに関するガイドラインです。このRFCの目的は、VPLSネットワークでのマルチキャストトラフィックの効率的な配信を実現するための手法を提供することです。
Internet Engineering Task Force (IETF) R. Aggarwal, Ed.
Request for Comments: 7117 Juniper Networks
Category: Standards Track Y. Kamite
ISSN: 2070-1721 NTT Communications
L. Fang
Microsoft
Y. Rekhter
Juniper Networks
C. Kodeboniya
February 2014
Multicast in Virtual Private LAN Service (VPLS)
仮想プライベートLANサービス（VPLS）でのマルチキャスト
Abstract
概要
RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.
RFC 4761および4762は、マルチキャストトラフィックを運ぶためにポイントツーポイントまたはマルチポイントツーポイントのユニキャストラベルスイッチドパス（LSP）の使用に依存する仮想プライベートLANサービス（VPLS）マルチキャストのソリューションを記述しています。このソリューションには、特定のVPLSマルチキャストトラフィックプロファイルに対して特定の制限があります。たとえば、大量のマルチキャストトラフィックを転送する場合、帯域幅の使用率が非常に最適化されないことがあります。
This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.
このドキュメントでは、既存のVPLSマルチキャストソリューションの制限のサブセットを克服するためのソリューションについて説明します。サービスプロバイダー（SP）ネットワークでマルチキャストツリーを利用するVPLSマルチキャストの手順について説明します。このドキュメントで説明するソリューションでは、複数のVPLSインスタンス間でこのようなマルチキャストツリーを共有できます。さらに、このドキュメントで説明するソリューションでは、SPネットワークの単一のマルチキャストツリーが、1つ以上のVPLSインスタンスからの1つ以上のIPマルチキャストストリームの指定されたセットにのみ属するトラフィックを伝送できます。
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/rfc7117.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7117で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Specification of Requirements ..............................6
3. Overview ........................................................6
3.1. Inclusive and Selective Multicast Trees ....................7
3.2. BGP-Based VPLS Membership Auto-discovery ...................8
3.3. IP Multicast Group Membership Discovery ....................8
3.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding ...9
3.5. Aggregation ...............................................10
3.6. Inter-AS VPLS Multicast ...................................11
4. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding .....12
4.1. Originating Intra-AS VPLS A-D Routes ......................13
4.2. Receiving Intra-AS VPLS A-D Routes ........................14
5. Demultiplexing P-Multicast Tree Traffic ........................15
5.1. One P-Multicast Tree - One VPLS Mapping ...................15
5.2. One P-Multicast Tree - Many VPLS Mapping ..................15
6. Establishing P-Multicast Trees .................................16
6.1. Common Procedures .........................................16
6.2. RSVP-TE P2MP LSPs .........................................16
6.2.1. P2MP TE LSP - VPLS Mapping .........................17
6.3. Receiver-Initiated P2MP LSP ...............................18
6.3.1. P2MP LSP - VPLS Mapping ............................18
6.4. Encapsulation of Aggregate P-Multicast Trees ..............18
7. Inter-AS Inclusive P-Multicast Tree A-D/Binding ................18
7.1. VSIs on the ASBRs .........................................19
7.1.1. Option (a): VSIs on the ASBRs ......................19
7.1.2. Option (e): VSIs on the ASBRs ......................20
7.2. Option (b) - Segmented Inter-AS Trees .....................20
7.2.1. Segmented Inter-AS Trees VPLS Inter-AS
A-D/Binding ........................................20
7.2.2. Propagating BGP VPLS A-D Routes to Other
ASes: Overview .....................................21
7.2.2.1. Propagating Intra-AS VPLS A-D
Routes in EBGP ............................23
7.2.2.2. Inter-AS A-D Route Received via EBGP ......23
7.2.2.3. Leaf A-D Route Received via EBGP ..........25
7.2.2.4. Inter-AS A-D Route Received via IBGP ......25
7.3. Option (c): Non-segmented Tunnels .........................26
8. Optimizing Multicast Distribution via Selective Trees ..........27
8.1. Protocol for Switching to Selective Trees .................29
8.2. Advertising (C-S, C-G) Binding to a Selective Tree ........30
8.3. Receiving S-PMSI A-D Routes by PEs ........................32
8.4. Inter-AS Selective Tree ...................................34
8.4.1. VSIs on the ASBRs ..................................35
8.4.1.1. VPLS Inter-AS Selective Tree A-D Binding ..35
8.4.2. Inter-AS Segmented Selective Trees .................35
8.4.2.1. Handling S-PMSI A-D Routes by ASBRs .......36
8.4.2.1.1. Merging Selective Tree
into an Inclusive Tree .........37
8.4.3. Inter-AS Non-segmented Selective Trees .............38
9. BGP Extensions .................................................38
9.1. Inclusive Tree/Selective Tree Identifier ..................38
9.2. MCAST-VPLS NLRI ...........................................39
9.2.1. S-PMSI A-D Route ...................................40
9.2.2. Leaf A-D Route .....................................41
10. Aggregation Considerations ....................................41
11. Data Forwarding ...............................................43
11.1. MPLS Tree Encapsulation ..................................43
11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP .....43
11.1.2. Mapping One VPLS Instance to a P2MP LSP ...........44
12. VPLS Data Packet Treatment ....................................45
13. Security Considerations .......................................46
14. IANA Considerations ...........................................47
15. References ....................................................47
15.1. Normative References .....................................47
15.2. Informative References ...................................48
16. Acknowledgments ...............................................50
[RFC4761] and [RFC4762] describe a solution for VPLS multicast/broadcast that relies on the use of pseudowires transported over unicast point-to-point (P2P) RSVP Traffic Engineering (RSVP-TE) or multipoint-to-point (MP2P) LDP Label Switched Paths (LSPs) ([RFC3209] [RFC5036]). In this document, we refer to this solution as "ingress replication".
[RFC4761]と[RFC4762]は、ユニキャストポイントツーポイント（P2P）RSVPトラフィックエンジニアリング（RSVP-TE）またはマルチポイントツーポイント（MP2P）を介して転送される疑似配線の使用に依存するVPLSマルチキャスト/ブロードキャストのソリューションを説明していますLDPラベルスイッチドパス（LSP）（[RFC3209] [RFC5036]）。このドキュメントでは、このソリューションを「入力レプリケーション」と呼びます。
With ingress replication, when an ingress Provider Edge (PE) of a given VPLS instance receives a multicast/broadcast packet from one of the Customer Edges (CEs) that belong to that instance, the ingress PE replicates the packet for each egress PE that belong to that instance, and it sends the packet to each such egress PE using unicast tunnels.
入力レプリケーションでは、特定のVPLSインスタンスの入力プロバイダーエッジ（PE）が、そのインスタンスに属するカスタマーエッジ（CE）の1つからマルチキャスト/ブロードキャストパケットを受信すると、入力PEは、属する各出力PEのパケットを複製しますそのインスタンスに送信し、ユニキャストトンネルを使用してそのような各出力PEにパケットを送信します。
The solution based on ingress replication has certain limitations for certain VPLS multicast/broadcast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization in the MPLS network when a large amount of multicast/broadcast traffic is to be transported (for more see [RFC5501]).
入力レプリケーションに基づくソリューションには、特定のVPLSマルチキャスト/ブロードキャストトラフィックプロファイルに対して特定の制限があります。たとえば、大量のマルチキャスト/ブロードキャストトラフィックが転送される場合、MPLSネットワークで帯域幅の使用率が非常に最適化されない可能性があります（詳細は[RFC5501]を参照）。
Ingress replication may be an acceptable model when the bandwidth of the multicast/broadcast traffic is low and/or there is a small number of replications performed on each outgoing interface for a particular VPLS customer multicast stream. If this is not the case, it is desirable to utilize multicast trees in the SP network to transmit VPLS multicast and/or broadcast packets [RFC5501].
マルチキャスト/ブロードキャストトラフィックの帯域幅が低い場合や、特定のVPLSカスタマーマルチキャストストリームの各発信インターフェイスで実行されるレプリケーションの数が少ない場合は、入力レプリケーションが受け入れ可能なモデルになることがあります。そうでない場合は、SPネットワークのマルチキャストツリーを利用して、VPLSマルチキャストおよび/またはブロードキャストパケットを送信することが望ましいです[RFC5501]。
This document describes procedures for overcoming the limitations of existing VPLS multicast solutions. It describes procedures for using MPLS point-to-multipoint (P2MP) LSPs in the SP network to transport VPLS multicast and/or broadcast packets, where these LSPs are signaled by either P2MP RSVP-TE [RFC4875] or Multipoint LDP (mLDP) [RFC6388].
このドキュメントでは、既存のVPLSマルチキャストソリューションの制限を克服するための手順について説明します。 SPネットワークでMPLSポイントツーマルチポイント（P2MP）LSPを使用してVPLSマルチキャストおよび/またはブロードキャストパケットを転送する手順について説明します。これらのLSPは、P2MP RSVP-TE [RFC4875]またはマルチポイントLDP（mLDP）によって通知されます[ RFC6388]。
The procedures described in this document are applicable to both [RFC4761] and [RFC4762].
このドキュメントで説明されている手順は、[RFC4761]と[RFC4762]の両方に適用できます。
This document uses terminology described in [RFC4761] and [RFC4762].
このドキュメントでは、[RFC4761]と[RFC4762]で説明されている用語を使用します。
In this document, we refer to various auto-discovery routes, as "A-D routes".
このドキュメントでは、さまざまな自動検出ルートを「A-Dルート」と呼びます。
This document uses the prefix 'C' to refer to the customer control or data packets and 'P' to refer to the provider control or data packets. An IP (multicast source, multicast group) tuple is abbreviated to (S, G).
このドキュメントでは、プレフィックス「C」を使用してカスタマーコントロールまたはデータパケットを示し、「P」を使用してプロバイダーコントロールまたはデータパケットを示します。 IP（マルチキャストソース、マルチキャストグループ）タプルは（S、G）と省略されます。
An "Inclusive tree" is a single multicast distribution tree in the SP network that carries all the multicast traffic from one VPLS instance on a given PE.
「インクルーシブツリー」は、SPネットワーク内の単一のマルチキャスト配信ツリーであり、特定のPE上の1つのVPLSインスタンスからのすべてのマルチキャストトラフィックを伝送します。
An "Aggregate Inclusive tree" is a single multicast distribution tree in the SP network that carries all the multicast traffic from more than one VPLS instance on a given PE.
「Aggregate Inclusive tree」は、SPネットワーク内の単一のマルチキャスト配信ツリーであり、特定のPE上の複数のVPLSインスタンスからのすべてのマルチキャストトラフィックを伝送します。
A "Selective tree" is a single multicast distribution tree in the SP network that carries multicast traffic belonging only to a specified set of IP multicast streams, and all these streams belong to the same VPLS instance on a given PE. A Selective tree differs from an Inclusive tree in that it may reach a subset of the PEs reached by an Inclusive tree.
「選択ツリー」は、指定されたIPマルチキャストストリームのセットにのみ属するマルチキャストトラフィックを運ぶSPネットワーク内の単一のマルチキャスト配信ツリーであり、これらのストリームはすべて、特定のPE上の同じVPLSインスタンスに属しています。選択ツリーは、包含ツリーが到達するPEのサブセットに到達する可能性があるという点で、包含ツリーとは異なります。
An "Aggregate Selective tree" is a single multicast distribution tree in the SP network that carries multicast traffic belonging only to a specified set of IP multicast streams, and all these streams belong to more than one VPLS instance on a given PE.
「集約選択ツリー」は、指定されたIPマルチキャストストリームのセットにのみ属するマルチキャストトラフィックを運ぶSPネットワークの単一のマルチキャスト配信ツリーであり、これらのストリームはすべて、特定のPE上の複数のVPLSインスタンスに属しています。
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]で説明されているように解釈されます。
Procedures described in this document provide mechanisms that allow a single multicast distribution tree in the SP network to carry all the multicast traffic from one or more VPLS sites connected to a given PE, irrespective of whether these sites belong to the same or different VPLS instances. We refer to such a tree as an "Inclusive tree" if it carries multicast traffic from one VPLS instance on a given PE. We refer to such a tree as an "Aggregate Inclusive tree" if it carries multicast traffic from more than one VPLS instance on a given PE. See the "Inclusive and Selective Multicast Trees" section for further discussion on Inclusive trees.
このドキュメントで説明する手順は、SPネットワークの単一のマルチキャスト配信ツリーが、特定のPEに接続されている1つ以上のVPLSサイトからのすべてのマルチキャストトラフィックを、これらのサイトが同じまたは異なるVPLSインスタンスに属しているかどうかに関係なく伝送できるメカニズムを提供します。特定のPE上の1つのVPLSインスタンスからマルチキャストトラフィックを伝送する場合、そのようなツリーを「包含ツリー」と呼びます。特定のPE上の複数のVPLSインスタンスからのマルチキャストトラフィックを伝送する場合、そのようなツリーを「集約包括的ツリー」と呼びます。包括的ツリーの詳細については、「包括的で選択的なマルチキャストツリー」を参照してください。
To further improve bandwidth utilization for IP multicast streams, this document also provides procedures by which a single multicast distribution tree in the SP network can be used to carry traffic belonging only to a specified set of IP multicast streams, originated in one or more VPLS sites connected to a given PE, irrespective of whether these sites belong to the same or different VPLS instances. We refer to such a tree as a "Selective tree" if it carries the IP multicast stream(s) that belongs to the same VPLS instance on a given PE. We refer to such a tree as an "Aggregate Selective tree" if it carries the IP multicast streams that belong to different VPLS instances on a given PE. Use of Selective and/or Aggregate Selective trees allows multicast traffic, by default, to be carried on an Inclusive tree, while traffic from some specific IP multicast streams, e.g., high-bandwidth streams, could be carried on one of the Selective trees. See the "Inclusive and Selective Multicast Trees" section for further discussion on Selective trees.
IPマルチキャストストリームの帯域幅使用率をさらに向上させるために、このドキュメントでは、SPネットワークの単一のマルチキャスト配信ツリーを使用して、1つ以上のVPLSサイトで発信された特定のIPマルチキャストストリームのセットのみに属するトラフィックを伝送する手順も説明しますこれらのサイトが同じまたは異なるVPLSインスタンスに属しているかどうかに関係なく、特定のPEに接続されます。特定のPE上の同じVPLSインスタンスに属するIPマルチキャストストリームを運ぶ場合、そのようなツリーを「選択ツリー」と呼びます。特定のPE上の異なるVPLSインスタンスに属するIPマルチキャストストリームを伝送する場合、そのようなツリーを「集約選択ツリー」と呼びます。選択的ツリーまたは集約選択的ツリー、あるいはその両方を使用すると、デフォルトでマルチキャストトラフィックを包含ツリーで伝送できますが、高帯域幅ストリームなどの特定のIPマルチキャストストリームからのトラフィックは、選択ツリーの1つで伝送できます。選択的ツリーの詳細については、「包括的で選択的なマルチキャストツリー」を参照してください。
Note that this document covers the use of Selective trees only for carrying IP multicast streams. Any other use of such trees is outside the scope of this document.
このドキュメントでは、IPマルチキャストストリームを伝送するためだけの選択的ツリーの使用について説明しています。このようなツリーの他の使用は、このドキュメントの範囲外です。
Unicast packets destined to unknown Media Access Control (MAC) addresses (i.e., not learned yet at the ingress PE) in a given VPLS instance are flooded to remote PEs participating in the same VPLS instance. This flooding MAY still use ingress replication (as specified in [RFC4761] and [RFC4762]), or MAY use the procedures defined in this document to optimize flooding across the SP core.
特定のVPLSインスタンス内の不明なメディアアクセスコントロール（MAC）アドレス（つまり、入力PEでまだ学習されていない）宛てのユニキャストパケットは、同じVPLSインスタンスに参加しているリモートPEにフラッディングされます。このフラッディングは引き続き[[RFC4761]と[RFC4762]で指定されている）入力レプリケーションを使用する場合があります。または、このドキュメントで定義されている手順を使用して、SPコア全体のフラッディングを最適化できます。
While the use of multicast trees in the SP network can be beneficial when the bandwidth of the multicast traffic is high, or when it is desirable to optimize the number of copies of a multicast packet transmitted on a given link, this benefit comes at a cost of state in the SP network to build multicast trees and overhead to maintain this state.
SPネットワークでのマルチキャストツリーの使用は、マルチキャストトラフィックの帯域幅が大きい場合、または特定のリンクで送信されるマルチキャストパケットのコピー数を最適化することが望ましい場合にメリットがありますが、このメリットは犠牲になりますマルチキャストツリーを構築するためのSPネットワークの状態と、この状態を維持するためのオーバーヘッド。
Multicast trees used for VPLS can be of two types:
VPLSに使用されるマルチキャストツリーには、次の2つのタイプがあります。
+ Inclusive trees. This option supports the use of a single multicast distribution tree, referred to as an "Inclusive P-multicast tree", in the SP network to carry all the multicast traffic from a specified set of VPLS sites connected to a given PE. There is no assumption made with respect to whether or not this traffic is IP encapsulated. A particular P-multicast tree can be set up to carry the traffic originated by sites belonging to a single VPLS instance or to carry the traffic originated by sites belonging to different VPLS instances. In the context of this document, the ability to carry the traffic of more than one VPLS instance on the same P-multicast tree is called "aggregation". The tree includes every PE that is a member of any of the VPLS instances that are using the tree. This implies that a PE may receive multicast traffic for a multicast stream even if it doesn't have any receivers that are interested in receiving traffic for that stream.
+ 包括的な木。このオプションは、SPネットワークで「包括的Pマルチキャストツリー」と呼ばれる単一のマルチキャスト配信ツリーの使用をサポートし、特定のPEに接続されたVPLSサイトの指定されたセットからのすべてのマルチキャストトラフィックを伝送します。このトラフィックがIPカプセル化されているかどうかに関しては想定されていません。特定のPマルチキャストツリーは、単一のVPLSインスタンスに属するサイトから発信されたトラフィックを伝送するように、または異なるVPLSインスタンスに属するサイトから発信されたトラフィックを伝送するように設定できます。このドキュメントのコンテキストでは、同じPマルチキャストツリーで複数のVPLSインスタンスのトラフィックを伝送する機能を「集約」と呼びます。ツリーには、ツリーを使用しているVPLSインスタンスのいずれかのメンバーであるすべてのPEが含まれています。これは、そのストリームのトラフィックの受信に関心のあるレシーバーがない場合でも、PEがマルチキャストストリームのマルチキャストトラフィックを受信する可能性があることを意味します。
An Inclusive P-multicast tree, as defined in this document, is a P2MP tree. Thus, a P2MP tree is used to carry traffic only from VPLS sites that are connected to the PE that is the root of the tree.
このドキュメントで定義されている包括的Pマルチキャストツリーは、P2MPツリーです。したがって、P2MPツリーは、ツリーのルートであるPEに接続されているVPLSサイトからのトラフィックのみを伝送するために使用されます。
+ Selective trees. A Selective P-multicast tree is used by a PE to send IP multicast traffic for one or more specific IP multicast streams, received by the PE over PE-CE interfaces that belong to the same or different VPLS instances, to a subset of the PEs that belong to those VPLS instances. Each of the PEs in the subset should be on the path to a receiver of one or more multicast streams that are mapped onto the tree. In the context of this document, the ability to use the same P-multicast tree for multicast streams that belong to different VPLS instances is called "aggregation". The reason for having Selective P-multicast trees is to provide a PE the ability to create separate SP multicast trees for specific multicast streams, e.g., high-bandwidth multicast streams. This allows traffic for these multicast streams to reach only those PE routers that have receivers for these streams. This avoids flooding other PE routers in the VPLS instance.
+選択的な木。選択的PマルチキャストツリーはPEによって使用され、同じまたは異なるVPLSインスタンスに属するPE-CEインターフェイスを介してPEによって受信された1つ以上の特定のIPマルチキャストストリームのIPマルチキャストトラフィックをPEのサブセットに送信しますそれらのVPLSインスタンスに属しています。サブセット内の各PEは、ツリーにマップされている1つ以上のマルチキャストストリームのレシーバーへのパス上にある必要があります。このドキュメントのコンテキストでは、異なるVPLSインスタンスに属するマルチキャストストリームに同じPマルチキャストツリーを使用する機能を「集約」と呼びます。選択的Pマルチキャストツリーを使用する理由は、特定のマルチキャストストリーム（高帯域幅マルチキャストストリームなど）に対して個別のSPマルチキャストツリーを作成する機能をPEに提供するためです。これにより、これらのマルチキャストストリームのトラフィックは、これらのストリームのレシーバーを持つPEルータのみに到達できます。これにより、VPLSインスタンス内の他のPEルータのフラッディングが回避されます。
An SP can use both Inclusive P-multicast trees and Selective P-multicast trees or either of them for a given VPLS on a PE, based on local configuration. Inclusive P-multicast trees can be used for both IP and non-IP data multicast traffic, while Selective P-multicast trees, as previously stated, must be used only for IP multicast data traffic. The use of Selective P-multicast trees for non-IP multicast traffic is outside the scope of this document.
SPは、ローカル構成に基づいて、PE上の特定のVPLSに対して、包括的P-マルチキャストツリーと選択的P-マルチキャストツリーの両方、またはそのいずれかを使用できます。包括的Pマルチキャストツリーは、IPおよび非IPデータマルチキャストトラフィックの両方に使用できますが、前述のように、選択的PマルチキャストツリーはIPマルチキャストデータトラフィックにのみ使用する必要があります。非IPマルチキャストトラフィックに選択的Pマルチキャストツリーを使用することは、このドキュメントの範囲外です。
P-multicast trees in the SP network can be realized via a variety of technologies. For both Inclusive and Selective P-multicast trees, these technologies include P2MP LSPs created by RSVP-TE or mLDP. This document also describes the data plane encapsulations for supporting these technologies. Other technologies for realizing P-multicast trees are outside the scope of this document.
SPネットワークのPマルチキャストツリーは、さまざまなテクノロジーを介して実現できます。包括的および選択的Pマルチキャストツリーの両方で、これらのテクノロジーには、RSVP-TEまたはmLDPによって作成されたP2MP LSPが含まれます。このドキュメントでは、これらのテクノロジーをサポートするためのデータプレーンのカプセル化についても説明します。 Pマルチキャストツリーを実現するその他のテクノロジーは、このドキュメントの範囲外です。
Inclusive P-multicast trees may be established for one or more VPLS instances. In this case, aggregation can be performed (using either mLDP or P2MP RSVP-TE as the tunneling technology) or simple tunneling can be performed (using P2MP RSVP-TE tunneling). If either of these approaches is used, the PE acting as the root of a P2MP LSP must be able to discover the other PEs that have membership of each of the VPLS instances. Once the root PE discovers these other PEs, it includes them as leaves in the P-multicast tree (i.e., P2MP LSP). This document uses the BGP-based procedures described in [RFC4761] and [RFC6074] for discovering the VPLS membership of all PEs. For more on aggregation, see the "Aggregation Considerations" section. When no aggregation is performed and the tunneling technology is mLDP, then the root of the P2MP LSP need not discover the other PEs that are the leaves of that LSP tree.
包括的なPマルチキャストツリーは、1つ以上のVPLSインスタンスに対して確立できます。この場合、（トンネリングテクノロジーとしてmLDPまたはP2MP RSVP-TEを使用して）アグリゲーションを実行するか、（P2MP RSVP-TEトンネリングを使用して）単純なトンネリングを実行できます。これらのアプローチのいずれかが使用される場合、P2MP LSPのルートとして機能するPEは、各VPLSインスタンスのメンバーシップを持つ他のPEを検出できる必要があります。ルートPEがこれらの他のPEを検出すると、それらをPマルチキャストツリー（つまり、P2MP LSP）のリーフとして含めます。このドキュメントでは、[RFC4761]および[RFC6074]で説明されているBGPベースの手順を使用して、すべてのPEのVPLSメンバーシップを検出します。集約の詳細については、「集約に関する考慮事項」を参照してください。集約が実行されておらず、トンネリングテクノロジーがmLDPの場合、P2MP LSPのルートは、そのLSPツリーのリーフである他のPEを検出する必要はありません。
The leaves of the Inclusive P-multicast tree must also be able to auto-discover the identifier of the tree (note that this applies when the tree is established by either mLDP or P2MP RSVP-TE). Procedures to accomplish this are described in the "Advertising P-Multicast Tree to VPLS/C-Multicast Binding" section.
包含的Pマルチキャストツリーのリーフも、ツリーの識別子を自動検出できる必要があります（これは、ツリーがmLDPまたはP2MP RSVP-TEのいずれかによって確立された場合に適用されます）。これを実行する手順については、「VPLS / CマルチキャストバインディングへのPマルチキャストツリーのアドバタイズ」を参照してください。
The setup of a Selective P-multicast tree for one or more IP multicast (C-S, C-G)s, requires the ingress PE to learn the PEs that have receivers in one or more of these (C-S, C-G)s, in the following cases:
1つ以上のIPマルチキャスト（CS、CG）の選択的Pマルチキャストツリーのセットアップでは、次の場合に、これらの（CS、CG）の1つ以上にレシーバーがあるPEを学習するために、入力PEが必要です。 ：
+ When aggregation is used (with either mLDP or P2MP RSVP-TE as the tunneling technology), OR
+ 集約を使用する場合（トンネリングテクノロジーとしてmLDPまたはP2MP RSVP-TEを使用）、または
+ When the tunneling technology is P2MP RSVP-TE
+ トンネリング技術がP2MP RSVP-TEの場合
+ If ingress replication is used and the ingress PE wants to send traffic for (C-S, C-G)s to only those PEs that are on the path to receivers for the (C-S, C-G)s.
+ 入力レプリケーションが使用され、入力PEが（C-S、C-G）の受信者へのパス上にあるPEのみに（C-S、C-G）のトラフィックを送信する場合。
For more on aggregation, see the "Aggregation Considerations" section.
集約の詳細については、「集約に関する考慮事項」を参照してください。
For discovering the IP multicast group membership, this document describes procedures that allow an ingress PE to enable explicit tracking of IP multicast membership. Thus, an ingress PE can request the IP multicast membership from egress PEs for one or more C-multicast streams. These procedures are described in the "Optimizing Multicast Distribution via Selective Trees" section.
このドキュメントでは、IPマルチキャストグループメンバーシップを検出するために、入力PEでIPマルチキャストメンバーシップの明示的な追跡を有効にする手順について説明します。したがって、入力PEは、1つ以上のCマルチキャストストリームについて、出力PEからのIPマルチキャストメンバーシップを要求できます。これらの手順については、「選択的ツリーによるマルチキャスト配信の最適化」で説明しています。
These procedures are applicable when IGMP ([RFC2236] [RFC3376]) or MLD ([RFC2710] [RFC3810]) is used as the multicast signaling protocol between the VPLS CEs. They are also applicable when PIM ([RFC4601]) in either the Any-Source Multicast (ASM) or the Source-Specific Multicast (SSM) service model is used as the multicast routing protocol between the VPLS CEs, and PIM join suppression is disabled on all the CEs.
これらの手順は、VPLS CE間のマルチキャストシグナリングプロトコルとしてIGMP（[RFC2236] [RFC3376]）またはMLD（[RFC2710] [RFC3810]）が使用されている場合に適用できます。これらは、Any-Source Multicast（ASM）またはSource-Specific Multicast（SSM）サービスモデルのいずれかのPIM（[RFC4601]）がVPLS CE間のマルチキャストルーティングプロトコルとして使用され、PIM加入抑制が無効になっている場合にも適用されます。すべてのCEで。
However, these procedures do not apply when PIM is used as the multicast routing protocol between the VPLS CEs and PIM join suppression is not disabled on all the CEs. This is because when PIM join suppression is not disabled on all the CEs, PEs connected to these CEs can not rely on PIM to determine IP multicast membership of the receivers behind these CEs. Procedures for this case are outside the scope of this document.
ただし、VPLS CE間のマルチキャストルーティングプロトコルとしてPIMが使用され、すべてのCEでPIM加入抑制が無効になっていない場合、これらの手順は適用されません。これは、すべてのCEでPIM加入抑制が無効になっていない場合、これらのCEに接続されているPEは、PIMに依存してこれらのCEの背後にあるレシーバーのIPマルチキャストメンバーシップを判断できないためです。このケースの手順は、このドキュメントの範囲外です。
The leaves of the Selective P-multicast trees must also be able to discover the identifier of these trees. Procedures to accomplish this are described in the "Advertising P-Multicast Tree to VPLS/C-Multicast Binding" section.
選択的Pマルチキャストツリーのリーフも、これらのツリーの識別子を検出できる必要があります。これを実行する手順については、「VPLS / CマルチキャストバインディングへのPマルチキャストツリーのアドバタイズ」を参照してください。
This document describes procedures based on BGP VPLS Auto-Discovery (A-D) routes ([RFC4761] [RFC6074]) that are used by the root of an Aggregate P-multicast tree to advertise the Inclusive or Selective P-multicast tree binding and the demultiplexing information to the leaves of the tree. This document uses the Provider Multicast Service Interface (PMSI) Tunnel attribute defined [RFC6514] for this purpose.
このドキュメントでは、B VPLS Auto-Discovery（AD）ルート（[RFC4761] [RFC6074]）に基づく手順について説明します。これらのルートは、包括的Pマルチキャストツリーのルートが包括的または選択的P-マルチキャストツリーバインディングと逆多重化をアドバタイズするために使用します。木の葉への情報。このドキュメントでは、この目的のために[RFC6514]で定義されたプロバイダーマルチキャストサービスインターフェイス（PMSI）トンネル属性を使用します。
Once an ingress PE decides to bind a set of VPLS instances or customer multicast groups to an Inclusive P-multicast tree or a Selective P-multicast tree, the PE needs to announce this binding to other PEs in the network. This procedure is referred to as "Inclusive P-multicast tree binding distribution" or "Selective P-multicast tree binding distribution" and is performed using BGP. The decision to bind a set of VPLS instances or customer multicast groups is a local matter to the ingress, and is controlled via provisioning/configuration on that PE.
入力PEが一連のVPLSインスタンスまたはカスタマーマルチキャストグループを包括的P-マルチキャストツリーまたは選択的P-マルチキャストツリーにバインドすることを決定したら、PEはこのバインディングをネットワーク内の他のPEに通知する必要があります。この手順は、「包括的P-マルチキャストツリーバインディング配信」または「選択的P-マルチキャストツリーバインディング配信」と呼ばれ、BGPを使用して実行されます。一連のVPLSインスタンスまたはカスタマーマルチキャストグループをバインドするかどうかの決定は、ローカルでの問題であり、そのPEでのプロビジョニング/構成によって制御されます。
When an Aggregated Inclusive P-multicast tree is used by an ingress PE, this binding distribution implies that (a) an ingress PE MUST announce the binding of all VPLS instances bound to the Inclusive P-multicast tree and (b) other PEs that have these instances receive these announcements. The inner label assigned by the ingress PE for each VPLS MUST be included if more than one VPLS is bound to the same P-multicast tree. The Inclusive P-multicast tree Identifier MUST be included.
集約された包括的Pマルチキャストツリーが入力PEによって使用される場合、このバインディングの配布は、（a）入力PEが包括的PマルチキャストツリーにバインドされたすべてのVPLSインスタンスのバインディングを通知する必要があること、および（b）他のPEがこれらのインスタンスはこれらのアナウンスを受け取ります。複数のVPLSが同じPマルチキャストツリーにバインドされている場合、各VPLSの入力PEによって割り当てられた内部ラベルを含める必要があります。包括的P-マルチキャストツリー識別子を含める必要があります。
For a Selective P-multicast tree, this binding distribution implies announcing all the specific <C-S, C-G> entries bound to this P-multicast tree along with the Selective P-multicast tree Identifier. The inner label assigned for each <C-S, C-G> MUST be included if <C-S, C-G> from different VPLS instances are bound to the same P-multicast tree. The labels MUST be distinct on a per-VPLS basis and MAY be distinct per <C-S, C-G> entry. The Selective P-multicast tree Identifier MUST be included.
選択的P-マルチキャストツリーの場合、このバインディング配布は、選択的P-マルチキャストツリー識別子とともに、このP-マルチキャストツリーにバインドされたすべての特定の<C-S、C-G>エントリを発表することを意味します。異なるVPLSインスタンスからの<C-S、C-G>が同じPマルチキャストツリーにバインドされている場合、各<C-S、C-G>に割り当てられた内部ラベルを含める必要があります。ラベルは、VPLSごとに区別する必要があり、<C-S、C-G>エントリごとに区別する必要があります。選択的Pマルチキャストツリー識別子を含める必要があります。
As described earlier in this document, the ability to carry the traffic of more than one VPLS on the same P-multicast tree is called aggregation.
このドキュメントで前述したように、同じPマルチキャストツリーで複数のVPLSのトラフィックを伝送する機能は、集約と呼ばれます。
Aggregation enables the SP to place a bound on the amount of multicast tree forwarding and control plane state that the P-routers must have. Let us call the number of VPLS instances aggregated onto a single P-multicast tree the "Aggregation Factor". When Inclusive source P-multicast trees are used, the number of trees that a PE is the root of is proportional to the number of VPLS instances on the PE divided by the Aggregation Factor.
アグリゲーションにより、SPは、P-routerが持つ必要があるマルチキャストツリー転送とコントロールプレーンの状態の量に制限を設けることができます。単一のPマルチキャストツリーに集約されたVPLSインスタンスの数を「集約係数」と呼びます。包含ソースPマルチキャストツリーを使用する場合、PEのルートであるツリーの数は、PE上のVPLSインスタンスの数を集約係数で割った値に比例します。
In this case, the state maintained by a P-router is proportional to:
この場合、Pルーターによって維持される状態は、以下に比例します。
AveVPLS NPE
------- X --------
Aggr AvePTree
Where:
ただし：
AveVPLS is the average number of VPLS instances on a PE
AveVPLSは、PE上のVPLSインスタンスの平均数です
Aggr is the Aggregation Factor
Aggrは集約要素です
NPE is the number of PEs
NPEはPEの数です
AvePTree is the average number of P-multicast that transit a given P-router
AvePTreeは、特定のPルーターを通過するPマルチキャストの平均数です
Thus, the state does not grow linearly with the number of VPLS instances.
したがって、状態はVPLSインスタンスの数に比例して増加しません。
Aggregation requires a mechanism for the egresses of the P-multicast tree to demultiplex the multicast traffic received over the P-multicast tree. To enable the egress nodes to perform this demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned and distributed by the root of the aggregate P-multicast tree.
集約には、Pマルチキャストツリーの出力がPマルチキャストツリーを介して受信したマルチキャストトラフィックを逆多重化するメカニズムが必要です。出力ノードがこの逆多重化を実行できるようにするには、アップストリーム割り当てラベル[RFC5331]を割り当て、集約Pマルチキャストツリーのルートによって配布する必要があります。
Aggregation procedures would require two MPLS labels in the label stack. This does not introduce any new implications on MTU, as even VPLS multicast supported by ingress replication requires two MPLS labels in the label stack.
集約手順では、ラベルスタックに2つのMPLSラベルが必要です。これは、MTUに新しい影響をもたらすことはありません。入力レプリケーションによってサポートされるVPLSマルチキャストでさえ、ラベルスタックに2つのMPLSラベルが必要であるためです。
This document defines four models of inter-AS (Autonomous System) VPLS service, referred here as options (a), (b), (c), and (e). Options (a), (b), and (c) defined in this document are very similar to methods (a), (b), and (c), described in the "Multi-AS VPLS" section of [RFC4761], which in turn extends the concepts of [RFC4364] to inter-AS VPLS.
このドキュメントでは、AS（自律システム）VPLSサービスの4つのモデルを定義します。ここでは、オプション（a）、（b）、（c）、および（e）と呼びます。このドキュメントで定義されているオプション（a）、（b）、および（c）は、[RFC4761]の「Multi-AS VPLS」セクションで説明されている方法（a）、（b）、および（c）と非常に似ています。次に、[RFC4364]の概念をAS間VPLSに拡張します。
For option (a) and option (b) support, this document specifies a model where inter-AS VPLS service can be offered without requiring a single P-multicast tree to span multiple ASes. There are two variants of this model, and they are described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section.
オプション（a）およびオプション（b）のサポートについて、このドキュメントでは、単一のPマルチキャストツリーが複数のASにまたがることなく、AS間VPLSサービスを提供できるモデルを指定します。このモデルには2つのバリアントがあり、「Inter-AS Inclusive P-Multicast Tree A-D / Binding」セクションで説明されています。
For option (c) support, this document specifies a model where inter-AS VPLS service is offered by requiring a single P-multicast tree to span multiple ASes. This is because in the case of option (c), the Autonomous System Border Routers (ASBRs) do not exchange BGP-VPLS Network Layer Reachability Information (NLRI) or A-D routes.
オプション（c）のサポートについて、このドキュメントでは、複数のASにまたがる単一のPマルチキャストツリーを要求することにより、AS間VPLSサービスが提供されるモデルを指定します。これは、オプション（c）の場合、自律システム境界ルーター（ASBR）がBGP-VPLSネットワーク層到達可能性情報（NLRI）またはA-Dルートを交換しないためです。
In addition to options (a), (b), and (c), this document also specifies option (e), which one may think of as a variant of option (a).
このドキュメントでは、オプション（a）、（b）、および（c）に加えて、オプション（e）も指定しています。
For more on these inter-AS options, see the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section.
これらのInter-ASオプションの詳細については、「Inter-ASを含むPマルチキャストツリーA-D /バインディング」を参照してください。
This section specifies procedures for the intra-AS auto-discovery of VPLS membership and the distribution of information used to instantiate P-multicast Tunnels.
このセクションでは、VPLSメンバーシップのAS内自動検出の手順と、Pマルチキャストトンネルのインスタンス化に使用される情報の配布について説明します。
VPLS auto-discovery/binding consists of two components: intra-AS and inter-AS. The former provides VPLS auto-discovery/binding within a single AS. The latter provides VPLS auto-discovery/binding across multiple ASes. Inter-AS auto-discovery/binding is described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section.
VPLS自動検出/バインディングは、ASA内およびAS間という2つのコンポーネントで構成されています。前者は、単一のAS内でのVPLS自動検出/バインディングを提供します。後者は、複数のASにまたがるVPLS自動検出/バインディングを提供します。 AS間自動検出/バインディングについては、「AS間包括的PマルチキャストツリーA-D /バインディング」で説明しています。
VPLS auto-discovery using BGP, as described in [RFC4761] and
[RFC6074], enables a PE to learn the VPLS instance membership of
other PEs. A PE that belongs to a particular VPLS instance announces
a BGP NLRI that identifies the Virtual Switch Instance (VSI). This
NLRI is constructed from the <Route Distinguisher (RD), VPLS Edge
Device Identifier (VE-ID)> tuple. The NLRI defined in [RFC4761]
comprises the <RD, VE-ID> tuple and label blocks for pseudowire (PW)
signaling. The VE-ID in this case is a two-octet number encoded in
the VE-ID of NLRI defined in [RFC4761]. The NLRI defined in
[RFC6074] comprises only the <RD, PE_addr>. The VE-ID in this case
is a four-octet number encoded in the PE_addr of the NLRI defined in
[RFC6074].
The procedures for constructing Inclusive Intra-AS and Inter-AS trees, as specified in this document, require the BGP A-D NLRI to carry only the <RD, VE-ID>. Hence, these procedures can be used for both BGP-VPLS and LDP-VPLS with BGP A-D.
このドキュメントで指定されているように、インクルーシブIntra-ASおよびInter-ASツリーを構築する手順では、BGP A-D NLRIが<RD、VE-ID>のみを伝送する必要があります。したがって、これらの手順は、BGP A-Dを使用するBGP-VPLSとLDP-VPLSの両方に使用できます。
It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. However, it is not an inherent feature of LDP-VPLS. In fact, there are deployments and/or implementations of LDP-VPLS that require configuration to enable a PE in a particular VPLS to determine other PEs in the VPLS and exchange PW labels using Forwarding Equivalence Class (FEC) 128 (PWid FEC) [RFC4447]. The use of BGP A-D for LDP-VPLS [RFC6074], to enable automatic setup of PWs, requires FEC 129 (Generalized PWid FEC) [RFC4447]. However, FEC 129 is not required in order to use procedures in this document for LDP-VPLS. An LDP-VPLS implementation that supports this document MUST support the BGP A-D procedures to set up P-multicast trees, as described here, and it MAY support FEC 129 to automate the signaling of PWs.
BGP A-DはBGP-VPLSの固有の機能であることに注意してください。ただし、LDP-VPLSに固有の機能ではありません。実際、特定のVPLS内のPEがVPLS内の他のPEを決定し、Forwarding Equivalence Class（FEC）128（PWid FEC）[RFC4447 ]。 LW-VPLSのBGP A-D [RFC6074]を使用してPWの自動セットアップを有効にするには、FEC 129（一般化PWid FEC）[RFC4447]が必要です。ただし、このドキュメントの手順をLDP-VPLSに使用するためにFEC 129は必要ありません。このドキュメントをサポートするLDP-VPLS実装は、ここで説明するように、PGPマルチキャストツリーをセットアップするBGP A-D手順をサポートする必要があり、PWのシグナリングを自動化するFEC 129をサポートする場合があります。
To participate in the VPLS auto-discovery/binding, a PE router that has a given VSI of a given VPLS instance originates a BGP VPLS Intra-AS A-D route and advertises this route in Multiprotocol (MP) IBGP. The route is constructed as described in [RFC4761] and [RFC6074].
VPLS自動検出/バインディングに参加するために、特定のVPLSインスタンスの特定のVSIを持つPEルーターは、BGP VPLS Intra-AS A-Dルートを開始し、このルートをマルチプロトコル（MP）IBGPでアドバタイズします。ルートは、[RFC4761]と[RFC6074]で説明されているように構築されます。
The route carries a single Layer 2 Virtual Private Network (L2VPN) NLRI with the RD set to the RD of the VSI and the VE-ID set to the VE-ID of the VSI. The route also carries one or more Route Targets (RTs), as specified in [RFC4761] and [RFC6074].
ルートは、RDがVSIのRDに設定され、VE-IDがVSIのVE-IDに設定された単一のレイヤー2仮想プライベートネットワーク（L2VPN）NLRIを伝送します。 [RFC4761]と[RFC6074]で指定されているように、ルートには1つ以上のルートターゲット（RT）も含まれます。
If an Inclusive P-multicast tree is used to instantiate the provider tunnel for VPLS multicast on the PE, the advertising PE MUST advertise the type and the identity of the P-multicast tree in the PMSI Tunnel attribute. This attribute is described in the "Inclusive Tree/Selective Tree Identifier" section.
包含Pマルチキャストツリーを使用して、PEでVPLSマルチキャストのプロバイダートンネルをインスタンス化する場合、アドバタイジングPEは、PMSIトンネル属性でPマルチキャストツリーのタイプとIDを通知する必要があります。この属性については、「包括的ツリー/選択的ツリー識別子」セクションで説明しています。
A PE that uses an Inclusive P-multicast tree to instantiate the provider tunnel MAY aggregate two or more VPLS instances present on the PE onto the same tree. If the PE decides to perform aggregation after it has already advertised the intra-AS VPLS A-D routes for these VPLS instances, then aggregation requires the PE to re-advertise these routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute (the re-advertised route will replace the previously advertised route). If the PE has not previously advertised Intra-AS A-D routes for these VPLS instances, then the aggregation requires the PE to advertise (new) Intra-AS A-D routes for these VPLS instances. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the VPLS instances as well as an MPLS upstream-assigned label [RFC5331]. Each re-advertised or newly advertised route MUST have a label that is distinct within the scope of the PE that advertises the route.
包括的Pマルチキャストツリーを使用してプロバイダートンネルをインスタンス化するPEは、PEに存在する2つ以上のVPLSインスタンスを同じツリーに集約できます（MAY）。 PEがこれらのVPLSインスタンスのAS内VPLS A-Dルートをすでにアドバタイズした後で集約を実行することを決定した場合、集約はこれらのルートを再アドバタイズする必要があります。再アドバタイズされたルートは、PMSIトンネル属性を除いて、元のルートと同じである必要があります（再アドバタイズされたルートは、以前にアドバタイズされたルートを置き換えます）。 PEがこれらのVPLSインスタンスのIntra-AS A-Dルートを以前にアドバタイズしていない場合、集約では、PEがこれらのVPLSインスタンスの（新しい）Intra-AS A-Dルートをアドバタイズする必要があります。新たにアドバタイズ/再アドバタイズされたルートのPMSIトンネル属性は、VPLSインスタンスとMPLSアップストリーム割り当てラベル[RFC5331]を集約するPマルチキャストツリーのIDを運ぶ必要があります。再アドバタイズまたは新しくアドバタイズされた各ルートには、ルートをアドバタイズするPEのスコープ内で異なるラベルが必要です。
Discovery of PE capabilities in terms of what tunnel types they support is outside the scope of this document. Within a given AS, PEs participating in a VPLS are expected to advertise tunnel bindings whose tunnel types are supported by all other PEs that are participating in this VPLS and are part of the same AS.
サポートするトンネルタイプに関するPE機能の発見は、このドキュメントの範囲外です。特定のAS内で、VPLSに参加しているPEは、このVPLSに参加していて同じASの一部である他のすべてのPEによってトンネルタイプがサポートされているトンネルバインディングをアドバタイズすることが期待されています。
When a PE receives a BGP Update message that carries an Intra-AS A-D route such that (a) the route was originated by some other PE within the same AS as the local PE, (b) at least one of the RTs of the route matches one of the import RTs configured for a particular VSI on the local PE, (c) the BGP route selection determines that this is the best route with respect to the NLRI carried by the route, and (d) the route carries the PMSI Tunnel attribute, the PE performs the following:
PEがIntra-AS ADルートを運ぶBGP更新メッセージを受信すると、（a）ルートはローカルPEと同じAS内の他のPEによって発信された、（b）ルートの少なくとも1つのRTローカルPE上の特定のVSI用に構成されたインポートRTの1つに一致します。（c）BGPルート選択は、これがルートによって運ばれるNLRIに関して最良のルートであると判断し、（d）ルートはPMSIトンネルを運びます属性では、PEは以下を実行します。
+ If the Tunnel Type in the PMSI Tunnel attribute is set to LDP P2MP LSP, the PE SHOULD join the P-multicast tree whose identity is carried in the PMSI Tunnel attribute.
+ PMSIトンネル属性のトンネルタイプがLDP P2MP LSPに設定されている場合、PEは、IDがPMSIトンネル属性で伝達されるPマルチキャストツリーに参加する必要があります（SHOULD）。
+ If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, the receiving PE has to establish the appropriate state to properly handle the traffic received over that LSP. The PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. This LSP MAY have been established before the local PE receives the route.
+ PMSI Tunnel属性のTunnel TypeがRSVP-TE P2MP LSPに設定されている場合、受信側PEは適切な状態を確立して、そのLSPで受信したトラフィックを適切に処理する必要があります。ルートを発信したPEは、ローカルPEをリーフとしてRSVP-TE P2MP LSPを確立する必要があります。このLSPは、ローカルPEがルートを受信する前に確立されている場合があります。
+ If the PMSI Tunnel attribute does not carry a label, then all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received A-D route.
+ PMSIトンネル属性にラベルが付いていない場合、Pマルチキャストツリーで受信されたすべてのパケットは、PMSIトンネル属性によって識別され、いずれかのインポートRTと少なくとも1つ一致するVSIを使用して転送されます。受信したADルートのRT。
+ If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS label, then the egress PE MUST treat this as an upstream-assigned label, and all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, with that upstream label are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received Intra-AS A-D route.
+ PMSIトンネル属性のトンネルタイプがLDP P2MP LSPまたはRSVP-TE P2MP LSPに設定されており、属性がMPLSラベルも保持している場合、出力PEはこれをアップストリーム割り当てラベルとして扱い、すべてのパケットを受信する必要があります。 PMSIトンネル属性で識別されるPマルチキャストツリーで、そのアップストリームラベルが、受信したイントラAS ADルートのRTの1つと一致するインポートRTの少なくとも1つを持つVSIを使用して転送されます。
Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic, originated by VPLS sites connected to the PE, to the sites attached to other PEs, then the local PE MUST use the Originating Router's IP Address information carried in the Intra-AS A-D route to add the PE, that originated the route, as a leaf node to the LSP. This MUST be done irrespective of whether or not the received Intra-AS A-D route carries the PMSI Tunnel attribute.
さらに、ローカルPEがRSVP-TE P2MP LSPを使用して、PEに接続されたVPLSサイトから発信された（マルチキャスト）トラフィックを、他のPEに接続されたサイトに送信する場合、ローカルPEは、元のルーターのIPアドレス情報を使用する必要があります。ルート内のPEをリーフノードとしてLSPに追加するためのAS内ADルート。これは、受信したIntra-AS A-DルートがPMSIトンネル属性を持っているかどうかに関係なく実行する必要があります。
Demultiplexing received VPLS traffic requires the receiving PE to determine the VPLS instance to which the packet belongs. The egress PE can then perform a VPLS lookup to further forward the packet. It also requires the egress PE to determine the identity of the ingress PE for MAC learning, as described in the "VPLS Data Packet Treatment" section.
受信したVPLSトラフィックを逆多重化するには、受信PEがパケットが属するVPLSインスタンスを判別する必要があります。次に、出力PEはVPLSルックアップを実行して、パケットをさらに転送できます。 「VPLSデータパケットの処理」で説明されているように、MAC学習用の入力PEのIDを決定するために出力PEも必要です。
When a P-multicast tree is mapped to only one VPLS, determining the tree on which the packet is received is sufficient to determine the VPLS instance on which the packet is received. The tree is determined based on the tree encapsulation. If MPLS encapsulation is used, e.g., RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the tree. Penultimate Hop Popping (PHP) MUST be disabled on the MPLS LSP (RSVP-TE P2MP LSP or mLDP P2MP LSP).
Pマルチキャストツリーが1つのVPLSのみにマッピングされている場合、パケットが受信されるツリーを決定するだけで、パケットが受信されるVPLSインスタンスを決定できます。ツリーは、ツリーのカプセル化に基づいて決定されます。 MPLSカプセル化が使用されている場合（RSVP-TE P2MP LSPなど）、ツリーを決定するために外部MPLSラベルが使用されます。 Penultimate Hop Popping（PHP）は、MPLS LSP（RSVP-TE P2MP LSPまたはmLDP P2MP LSP）で無効にする必要があります。
As traffic belonging to multiple VPLS instances can be carried over the same tree, there is a need to identify the VPLS to which the packet belongs. This is done by using an inner label that determines the VPLS for which the packet is intended. The ingress PE uses this label as the inner label while encapsulating a customer multicast data packet. Each of the egress PEs must be able to associate this inner label with the same VPLS and use it to demultiplex the traffic received over the Aggregate Inclusive tree or the Aggregate Selective tree.
複数のVPLSインスタンスに属するトラフィックは同じツリー上で伝送できるため、パケットが属するVPLSを識別する必要があります。これは、パケットの対象となるVPLSを決定する内部ラベルを使用して行われます。入力PEは、カスタマーマルチキャストデータパケットをカプセル化するときに、このラベルを内部ラベルとして使用します。各出力PEは、この内部ラベルを同じVPLSに関連付け、それを使用して、Aggregate InclusiveツリーまたはAggregate Selectiveツリーで受信したトラフィックを逆多重化できる必要があります。
If traffic from multiple VPLS instances is carried on a single tree, upstream-assigned labels [RFC5331] MUST be used. Hence, the inner label is assigned by the ingress PE. When the egress PE receives a packet over an Aggregate tree, the outer encapsulation (in the case of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to perform the inner-label lookup. The same label space MUST be used by the egress PE for all P-multicast trees that have the same root [RFC5331].
複数のVPLSインスタンスからのトラフィックが単一のツリーで運ばれる場合、上流に割り当てられたラベル[RFC5331]を使用する必要があります。したがって、内部ラベルは入力PEによって割り当てられます。出力PEが集約ツリーを介してパケットを受信すると、外部カプセル化（MPLS P2MP LSPの場合、外部MPLSラベル）は、内部ラベルのルックアップを実行するためのラベルスペースを指定します。同じルート[RFC5331]を持つすべてのP-マルチキャストツリーの出力PEは、同じラベルスペースを使用する必要があります。
If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the outer MPLS label and, optionally, the incoming interface provide the label space of the label beneath it. This assumes that PHP is disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree once it is known to the egress PE that the tree is bound to one or more VPLS instances. Once the label representing the tree is popped off the MPLS label stack, the next label is the demultiplexing information that allows the proper VPLS instance to be determined.
RSVP-TE P2MP LSPのように、ツリーがMPLSカプセル化を使用する場合、外側のMPLSラベルと、オプションで着信インターフェイスが、その下にあるラベルのラベルスペースを提供します。これは、PHPが無効になっていることを前提としています。ツリーが1つ以上のVPLSインスタンスにバインドされていることが出力PEに認識されると、出力PEはそのツリーのIMPLICIT NULLまたはEXPLICIT NULLをアドバタイズしてはなりません（MUST NOT）。ツリーを表すラベルがMPLSラベルスタックからポップされると、次のラベルは、適切なVPLSインスタンスを決定できるようにする逆多重化情報になります。
The ingress PE informs the egress PEs about the inner label as part of the tree binding procedures described in the "BGP Extensions" section.
入力PEは、「BGP拡張」で説明したツリーバインディング手順の一部として、内部ラベルについて出力PEに通知します。
This document supports only P2MP P-multicast trees wherein it is possible for egress PEs to identify the ingress PE to perform MAC learning. Specific procedures are identified only for RSVP-TE P2MP LSPs and mLDP P2MP LSPs. An implementation that supports this document MUST support RSVP-TE P2MP LSPs and mLDP P2MP LSPs.
このドキュメントは、出力PEがMAC学習を実行するために入力PEを識別できるP2MP Pマルチキャストツリーのみをサポートします。特定の手順は、RSVP-TE P2MP LSPおよびmLDP P2MP LSPに対してのみ識別されます。このドキュメントをサポートする実装は、RSVP-TE P2MP LSPおよびmLDP P2MP LSPをサポートする必要があります。
The following procedures apply to both RSVP-TE P2MP and mLDP P2MP LSPs.
次の手順は、RSVP-TE P2MPとmLDP P2MP LSPの両方に適用されます。
Demultiplexing the C-multicast data packets at the egress PE requires that the PE must be able to determine the P2MP LSP on which the packets are received. This enables the egress PE to determine the VPLS instances to which the packet belongs. To achieve this, the LSP MUST be signaled with PHP off and a non-special purpose MPLS label off as described in the "Demultiplexing P-Multicast Tree Traffic" section. In other words, an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that is carrying traffic for one or more VPLS instances. This is because the egress PE needs to rely on the MPLS label, that it advertises to its upstream neighbor, to determine the P2MP LSP on which a C-multicast data packet is received.
出力PEでCマルチキャストデータパケットを逆多重化するには、PEがパケットを受信するP2MP LSPを決定できる必要があります。これにより、出力PEは、パケットが属するVPLSインスタンスを判別できます。これを実現するには、「Pマルチキャストツリートラフィックの逆多重化」セクションで説明されているように、LSPをPHPオフで、非特別目的のMPLSラベルをオフで通知する必要があります。言い換えると、出力PEは、1つ以上のVPLSインスタンスのトラフィックを伝送しているP2MP LSPのIMPLICIT NULLまたはEXPLICIT NULLをアドバタイズしてはなりません。これは、Cマルチキャストデータパケットが受信されるP2MP LSPを決定するために、出力PEがアップストリームネイバーにアドバタイズするMPLSラベルに依存する必要があるためです。
The egress PE also needs to identify the ingress PE to perform MAC learning. When P2MP LSPs are used as P2MP trees, determining the P2MP LSP on which the packets are received is sufficient to determine the ingress PE. This is because the ingress PE is the root of the P2MP LSP.
出力PEは、MAC学習を実行するために入力PEを識別する必要もあります。 P2MP LSPをP2MPツリーとして使用する場合、パケットが受信されるP2MP LSPを決定するだけで、入力PEを決定できます。これは、入力PEがP2MP LSPのルートであるためです。
The egress PE relies on receiving the PMSI Tunnel attribute in BGP to determine the VPLS instance to P2MP LSP mapping.
出力PEは、BGPのPMSIトンネル属性の受信に依存して、VPLSインスタンスからP2MP LSPへのマッピングを決定します。
This section describes procedures that are specific to the usage of RSVP-TE P2MP LSPs for instantiating a P-multicast tree. Procedures in [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the root of the P2MP LSP discovers the leaves. The egress PEs are discovered using the procedures described in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section. Aggregation, as described in this document, is supported.
このセクションでは、Pマルチキャストツリーをインスタンス化するためのRSVP-TE P2MP LSPの使用に固有の手順について説明します。 [RFC4875]の手順は、P2MP LSPを通知するために使用されます。 P2MP LSPのルートがリーフを検出すると、LSPが通知されます。出力PEは、「Intra-AS Inclusive P-Multicast Tree Auto-discovery / Binding」で説明されている手順を使用して検出されます。このドキュメントで説明されている集計はサポートされています。
P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP-based advertisements of the P2MP TE LSP - VPLS mapping. They require that the root of the tree include in the BGP advertisements the P2MP TE LSP identifier as the P-multicast tree identifier. This P-multicast tree identifier contains the following information elements:
P2MP TE LSPからVPLSへのマッピングは、P2MP TE LSP-VPLSマッピングのBGPベースのアドバタイズメントを使用して、出力PEで学習されます。ツリーのルートには、BGPアドバタイズメントにP2MP TE LSP識別子をPマルチキャストツリー識別子として含める必要があります。このPマルチキャストツリー識別子には、次の情報要素が含まれています。
- The type of the tunnel is set to RSVP-TE P2MP LSP - RSVP-TE P2MP LSP's SESSION Object
- トンネルのタイプはRSVP-TE P2MP LSP-RSVP-TE P2MP LSPのSESSIONオブジェクトに設定されています
See the "Inclusive Tree/Selective Tree Identifier" section for more details on how this tree identifier is carried in BGP advertisements.
このツリー識別子がBGPアドバタイズメントでどのように運ばれるかについての詳細は、「包括的ツリー/選択的ツリー識別子」を参照してください。
Once the egress PE receives the P2MP TE LSP to VPLS mapping:
出力PEがP2MP TE LSPからVPLSへのマッピングを受信すると、次のようになります。
+ If the egress PE already has RSVP-TE state for the P2MP TE LSP, it MUST begin to assign an MPLS label from the non-special purpose label range, for the P2MP TE LSP and signal this to the previous hop of the P2MP TE LSP. Further, it MUST create forwarding state to forward packets received on the P2MP LSP.
+ 出力PEがP2MP TE LSPのRSVP-TE状態をすでに持っている場合、P2MP TE LSPの非特殊目的ラベル範囲からMPLSラベルを割り当て始め、これをP2MP TE LSPの前のホップにシグナリングする必要があります。 。さらに、P2MP LSPで受信したパケットを転送する転送状態を作成する必要があります。
+ If the egress PE does not have RSVP-TE state for the P2MP TE LSP, it MUST retain this mapping. Subsequently, when the egress PE receives the RSVP-TE P2MP signaling message, it creates the RSVP-TE P2MP LSP state. It MUST then assign an MPLS label from the non-reserved label range, for the P2MP TE LSP, and signal this to the previous hop of the P2MP TE LSP.
+ 出力PEがP2MP TE LSPのRSVP-TE状態を持たない場合、このマッピングを保持する必要があります。その後、出力PEがRSVP-TE P2MPシグナリングメッセージを受信すると、RSVP-TE P2MP LSP状態が作成されます。次に、P2MP TE LSPの非予約ラベル範囲からMPLSラベルを割り当て、これをP2MP TE LSPの前のホップにシグナリングする必要があります。
Note that if the signaling to set up an RSVP-TE P2MP LSP is completed before a given egress PE learns, via a PMSI Tunnel attribute, of the VPLS or set of VPLS instances to which the LSP is bound, the PE MUST discard any traffic received on that LSP until the binding is received. In order for the egress PE to be able to discard such traffic, it needs to know that the LSP is associated with one or more VPLS instances and that the VPLS A-D route that binds the LSP to a VPLS has not yet been received. This is provided by extending [RFC4875] with [RFC6511].
RSVP-TE P2MP LSPをセットアップするためのシグナリングが、所定の出口PEがPMSIトンネル属性を介して、LSPがバインドされているVPLSまたはVPLSインスタンスのセットを学習する前に完了した場合、PEはすべてのトラフィックを破棄する必要があることに注意してください。バインディングが受信されるまで、そのLSPで受信されます。出力PEがこのようなトラフィックを破棄できるようにするには、LSPが1つ以上のVPLSインスタンスに関連付けられていること、およびLSPをVPLSにバインドするVPLS A-Dルートがまだ受信されていないことを認識する必要があります。これは、[RFC4875]を[RFC6511]で拡張することによって提供されます。
Receiver-initiated P2MP LSPs can also be used. The mLDP procedures ([RFC6388]) MUST be used to signal such LSPs. The LSP is signaled once the leaves receive the LDP FEC for the tree from the root, as described in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section. When aggregation is used, an ingress PE is required to discover the egress PEs (see the "Aggregation Considerations" section for the rationale), and this is achieved using the procedures in the "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding" section.
レシーバーによって開始されるP2MP LSPも使用できます。 mLDP手順（[RFC6388]）は、そのようなLSPを通知するために使用されなければなりません（MUST）。 「Intra-AS Inclusive P-Multicast Tree Auto-discovery / Binding」で説明されているように、リーフがツリーのLDP FECをルートから受信すると、LSPが通知されます。集約を使用する場合、出力PEを検出するために入力PEが必要であり（根拠については、「集約に関する考慮事項」セクションを参照）、これは「AS内のPマルチキャストツリーの自動検出/バインディング」セクション。
P2MP LSP to VPLS mapping is learned at the egress PEs using BGP-based advertisements of the P2MP LSP - VPLS mapping. They require that the root of the tree include in the BGP advertisements the P2MP LSP identifier as the P-multicast tree identifier. This P-multicast tree identifier contains the following information elements:
P2MP LSPからVPLSへのマッピングは、P2MP LSP-VPLSマッピングのBGPベースのアドバタイズメントを使用して、出力PEで学習されます。ツリーのルートには、BGPアドバタイズメントにP2MP LSP識別子をPマルチキャストツリー識別子として含める必要があります。このPマルチキャストツリー識別子には、次の情報要素が含まれています。
- The type of the tunnel is set to LDP P2MP LSP - LDP P2MP FEC that includes an identifier generated by the root.
- トンネルのタイプは、ルートによって生成された識別子を含むLDP P2MP LSP-LDP P2MP FECに設定されます。
See the "Inclusive Tree/Selective Tree Identifier" section for more details on how this tree identifier is carried in BGP advertisements.
このツリー識別子がBGPアドバタイズメントでどのように運ばれるかについての詳細は、「包括的ツリー/選択的ツリー識別子」を参照してください。
Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label mapping messages for the LDP P2MP FEC, that was learned in the BGP advertisement, using procedures described in [RFC6388].
[RFC6388]で説明されている手順を使用して、BGPアドバタイズメントで学習されたLDP P2MP FECのLDPラベルマッピングメッセージを送信することにより、各出力PEはP2MP MPLSツリーに「参加」する必要があります。
An Aggregate Inclusive P-multicast tree or an Aggregate Selective P-multicast tree MUST use MPLS encapsulation, as described in [RFC5332].
[RFC5332]で説明されているように、集約包括的Pマルチキャストツリーまたは集約選択的Pマルチキャストツリーは、MPLSカプセル化を使用する必要があります。
As stated earlier, this document defines four models of inter-AS VPLS service, referred here as option (a), (b), (c), and (e). This section contains procedures to support these models.
前述のように、このドキュメントでは、AS間VPLSサービスの4つのモデルを定義します。ここでは、オプション（a）、（b）、（c）、および（e）と呼びます。このセクションでは、これらのモデルをサポートする手順について説明します。
For supporting option (a), (b), and (e), this section specifies a model where inter-AS VPLS service can be offered without requiring a single P-multicast tree to span multiple ASes. This allows individual ASes to potentially use different P-tunneling technologies. There are two variants of this model. One that requires MAC lookup on the ASBRs and applies to option (a) and (e). The other is one that does not require MAC lookup on the ASBRs, and instead it builds segmented Inter-AS Inclusive or Selective trees. This applies only to option (b).
オプション（a）、（b）、および（e）をサポートするために、このセクションでは、単一のPマルチキャストツリーが複数のASにまたがることなく、AS間VPLSサービスを提供できるモデルを指定します。これにより、個々のASが異なるPトンネリングテクノロジーを使用する可能性があります。このモデルには2つのバリアントがあります。 ASBRでMACルックアップを必要とし、オプション（a）および（e）に適用されるもの。もう1つは、ASBRでMACルックアップを必要としないもので、セグメント化されたInter-ASインクルーシブツリーまたは選択的ツリーを構築します。これはオプション（b）にのみ適用されます。
For supporting option (c), this section specifies a model where Inter-AS VPLS service is offered by requiring a single Inclusive P-multicast tree to span multiple ASes. This is referred to as a "non-segmented P-multicast tree". This is because in the case of option (c), the ASBRs do not exchange BGP-VPLS NLRIs or VPLS A-D routes. Support for Inter-AS Selective trees for option (c) may be segmented or non-segmented.
オプション（c）をサポートするために、このセクションでは、複数のASにまたがる単一の包括的Pマルチキャストツリーを要求することによってInter-AS VPLSサービスが提供されるモデルを指定します。これは、「非セグメント化P-マルチキャストツリー」と呼ばれます。これは、オプション（c）の場合、ASBRがBGP-VPLS NLRIまたはVPLS A-Dルートを交換しないためです。オプション（c）のInter-AS選択ツリーのサポートは、セグメント化されている場合とセグメント化されていない場合があります。
An implementation MUST support options (a), (b), and (c), and MAY support option (e). When there are multiple ways for implementing one of these options, this section specifies which one is mandatory.
実装はオプション（a）、（b）、および（c）をサポートする必要があり、オプション（e）をサポートする場合があります。これらのオプションの1つを実装する方法が複数ある場合、このセクションでは、どの方法が必須かを指定します。
When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC lookup, in addition to any MPLS lookups, to determine the forwarding decision on a VPLS packet. The P-multicast trees are confined to an AS. An ASBR on receiving a VPLS packet from another ASBR is required to perform a MAC lookup to determine how to forward the packet. Thus, an ASBR is required to keep a VSI for the VPLS instance and MUST be configured with its own VE-ID for the VPLS instance. The BGP VPLS A-D routes generated by PEs in an AS MUST NOT be propagated outside the AS.
VBRがASBRで構成されている場合、ASBRはMPLSルックアップに加えてMACルックアップを実行して、VPLSパケットの転送決定を決定する必要があります。 PマルチキャストツリーはASに限定されます。別のASBRからVPLSパケットを受信したASBRは、MACルックアップを実行してパケットの転送方法を決定する必要があります。したがって、ASBRはVPLSインスタンスのVSIを維持する必要があり、VPLSインスタンスの独自のVE-IDで構成する必要があります。 AS内のPEによって生成されたBGP VPLS A-Dルートは、ASの外部に伝播してはいけません。
In option (a), an ASBR acts as a PE for the VPLSs that span the AS of the ASBR and an AS to which the ASBR is connected. The local ASBR views the ASBR in the neighboring AS as a CE connected to it by a link with separate VLAN sub-interfaces for each such VPLS. Similarly, the ASBR in the neighboring AS acts as a PE for such VPLS from the neighboring AS's point of view, and views the local ASBR as a CE.
オプション（a）では、ASBRは、ASBRのASとASBRが接続されているASにまたがるVPLSのPEとして機能します。ローカルASBRは、隣接するASのASBRを、そのようなVPLSごとに個別のVLANサブインターフェースを持つリンクによって接続されたCEとして表示します。同様に、隣接AS内のASBRは、隣接ASの視点からそのようなVPLSのPEとして機能し、ローカルASBRをCEとして表示します。
The local ASBR uses a combination of the incoming link and a particular VLAN sub-interface on that link to determine the VSI for the packets it receives from the ASBR in the neighboring AS.
ローカルASBRは、着信リンクとそのリンク上の特定のVLANサブインターフェイスの組み合わせを使用して、隣接ASのASBRから受信するパケットのVSIを決定します。
In option (a), the ASBRs do not exchange VPLS A-D routes.
オプション（a）では、ASBRはVPLS A-Dルートを交換しません。
An implementation MUST support option (a).
実装はオプション（a）をサポートする必要があります。
The VSIs on the ASBRs scheme can be used such that the interconnect between the ASBRs is a PW and MPLS encapsulation is used between the ASBRs. An ASBR in one AS determines the VSI for packets received from an adjoining ASBR in another AS based on the incoming MPLS PW label. This is referred to as "option (e)". The only VPLS A-D routes that are propagated outside the AS are the ones originated by ASBRs. This MPLS PW connects the VSIs on the ASBRs and MUST be signaled using the procedures defined in [RFC4761] or [RFC4762].
ASBRスキーム上のVSIは、ASBR間の相互接続がPWであり、MPLSカプセル化がASBR間で使用されるように使用できます。 1つのASのASBRは、着信MPLS PWラベルに基づいて、別のASの隣接するASBRから受信したパケットのVSIを決定します。これを「オプション（e）」といいます。 ASの外部に伝播される唯一のVPLS A-Dルートは、ASBRが発信したルートです。このMPLS PWは、ASBR上のVSIを接続し、[RFC4761]または[RFC4762]で定義された手順を使用してシグナリングされる必要があります。
The P-multicast trees for a VPLS are confined to each AS and the VPLS auto-discovery/binding MUST follow the intra-AS procedures described in the "Demultiplexing P-Multicast Tree Traffic" section.
VPLSのPマルチキャストツリーは各ASに限定され、VPLS自動検出/バインディングは、「Pマルチキャストツリートラフィックの逆多重化」で説明したAS内の手順に従う必要があります。
An implementation MAY support option (e).
実装はオプション（e）をサポートしてもよい（MAY）。
In this model, an inter-AS P-multicast tree, rooted at a particular PE for a particular VPLS instance, consists of a number of "segments", one per AS, which are stitched together at ASBRs. These are known as "segmented inter-AS trees". Each segment of a segmented inter-AS tree may use a different multicast transport technology. In this model, an ASBR is not required to keep a VSI for the VPLS instance, and is not required to perform a MAC lookup in order to forward the VPLS packet. This implies that an ASBR is not required to be configured with a VE-ID for the VPLS.
このモデルでは、特定のVPLSインスタンスの特定のPEをルートとするAS間Pマルチキャストツリーは、ASBRでつなぎ合わされた、ASごとに1つある複数の「セグメント」で構成されます。これらは「セグメント化されたAS間ツリー」として知られています。セグメント化されたInter-ASツリーの各セグメントは、異なるマルチキャストトランスポートテクノロジーを使用できます。このモデルでは、ASBRはVPLSインスタンスのVSIを維持する必要がなく、VPLSパケットを転送するためにMACルックアップを実行する必要もありません。これは、ASBRをVPLSのVE-IDで構成する必要がないことを意味します。
An implementation MUST support option (b) using this model.
実装は、このモデルを使用してオプション（b）をサポートする必要があります。
The construction of segmented inter-AS trees requires the BGP-VPLS A-D NLRI described in [RFC4761] and [RFC6074]. A BGP VPLS A-D route for an <RD, VE-ID> tuple advertised outside the AS, to which the originating PE belongs, will be referred to as an "Inter-AS VPLS A-D route" (though this route is originated by a PE as an intra-AS route, and is referred to as an "inter-AS route outside the AS").
セグメント化されたAS間ツリーの構築には、[RFC4761]および[RFC6074]で説明されているBGP-VPLS A-D NLRIが必要です。元のPEが属するASの外部にアドバタイズされた<RD、VE-ID>タプルのBGP VPLS ADルートは、「Inter-AS VPLS ADルート」と呼ばれます（このルートはPEによって発信されますが） AS内ルートとして、「AS外AS間ルート」と呼ばれます）。
In addition to this, segmented inter-AS trees require support for the PMSI Tunnel attribute described in the "Inclusive Tree/Selective Tree Identifier" section. They also require additional procedures in BGP to signal leaf A-D routes between ASBRs as explained in subsequent sections.
これに加えて、セグメント化されたAS間ツリーは、「包括的ツリー/選択的ツリー識別子」セクションで説明されているPMSIトンネル属性のサポートを必要とします。また、後続のセクションで説明するように、ASBR間のリーフA-DルートをシグナリングするためにBGPで追加の手順が必要です。
This section specifies the procedures for inter-AS VPLS A-D/binding for segmented Inter-AS trees.
このセクションでは、セグメント化されたInter-ASツリーのAS間VPLS A-D /バインディングの手順を指定します。
An ASBR must be configured to support a particular VPLS as follows:
ASBRは、次のように特定のVPLSをサポートするように設定する必要があります。
+ An ASBR MUST be configured with a set of (import) RTs that specify the set of VPLS instances supported by the ASBR. These RTs control acceptance of BGP VPLS auto-discovery routes by the ASBR. Note that instead of being configured, the ASBR MAY obtain this set of (import) RTs by using Route Target Constrain [RFC4684].
+ ASBRは、ASBRによってサポートされるVPLSインスタンスのセットを指定する（インポート）RTのセットで構成する必要があります。これらのRTは、ASBRによるBGP VPLS自動検出ルートの受け入れを制御します。 ASBRは設定される代わりに、ルートターゲット制約[RFC4684]を使用してこの（インポート）RTのセットを取得してもよいことに注意してください。
+ The ASBR MUST be configured with the tunnel types for the intra-AS segments of the VPLS instances supported by the ASBR, as well as (depending on the tunnel type) the information needed to create the PMSI Tunnel attribute for these tunnel types. Note that instead of being configured, the ASBR MAY derive the tunnel types from the Intra-AS A-D routes received by the ASBR from the PEs in its own AS.
+ ASBRは、ASBRによってサポートされるVPLSインスタンスのAS内セグメントのトンネルタイプ、および（トンネルタイプに応じて）これらのトンネルタイプのPMSIトンネル属性を作成するために必要な情報で構成する必要があります。 ASBRは、設定される代わりに、ASBRが自身のAS内のPEからASBRが受信したAS内A-Dルートからトンネルタイプを導出してもよいことに注意してください。
If an ASBR is configured to support a particular VPLS instance, the ASBR MUST participate in the intra-AS VPLS auto-discovery/binding procedures for that VPLS instance within the ASBR's own AS, as defined in this document.
ASBRが特定のVPLSインスタンスをサポートするように構成されている場合、ASBRは、このドキュメントで定義されているように、ASBR自身のAS内のそのVPLSインスタンスのAS内VPLS自動検出/バインディング手順に参加する必要があります。
Moreover, in addition to the above, the ASBR performs procedures specified in the "Propagating BGP VPLS A-D Routes to Other ASes: Overview" section.
さらに、上記に加えて、ASBRは「他のASへのBGP VPLS A-Dルートの伝播：概要」セクションで指定された手順を実行します。
A BGP VPLS A-D route for a given VPLS, originated by a PE within a given AS, is propagated via BGP to other ASes. The precise rules for distributing and processing the Inter-AS A-D routes are given in subsequent sections.
特定のAS内のPEから発信された特定のVPLSのBGP VPLS A-Dルートは、BGPを介して他のASに伝播されます。 Inter-AS A-Dルートの配布と処理の正確なルールは、後続のセクションで説明されています。
Suppose that an ASBR "A" receives and installs a BGP VPLS A-D route for VPLS "X" and VE-ID "V" that originated at a particular PE "PE1" that is in the same AS as A. The BGP next hop of that received route becomes A's "upstream neighbor" on a multicast distribution tree for (X, V) that is rooted at PE1. Likewise, when A re-advertises this route to ASBRs in A's neighboring ASes, from the perspective of these ASBRs A becomes their "upstream neighbor" on the multicast distribution tree for (X, V) that is rooted at PE1.
ASBR "A"が、Aと同じASにある特定のPE "PE1"から発信されたVPLS "X"およびVE-ID "V"のBGP VPLS ADルートを受信してインストールするとします。BGPの次のホップその受信されたルートは、PE1をルートとする（X、V）のマルチキャスト配布ツリー上のAの「上流ネイバー」になります。同様に、AがこのルートをAの隣接ASのASBRに再アドバタイズすると、これらのASBRの観点から、AはPE1をルートとする（X、V）のマルチキャスト配布ツリーの「上流ネイバー」になります。
When the BGP VPLS A-D routes have been distributed to all the necessary ASes, they define a "reverse path" from any AS that supports VPLS X and VE-ID V back to PE1. For instance, if AS2 supports VPLS X, then there will be a reverse path for VPLS X and VE ID V from AS2 to AS1. This path is a sequence of ASBRs, the first of which is in AS2 and the last of which is in AS1. Each ASBR in the sequence is the BGP next hop of the previous ASBR in the sequence.
BGP VPLS A-Dルートが必要なすべてのASに配布されると、VPLS XおよびVE-ID VをサポートするASからPE1に戻る「リバースパス」が定義されます。たとえば、AS2がVPLS Xをサポートしている場合、AS2からAS1へのVPLS XおよびVE ID Vのリバースパスが存在します。このパスはASBRのシーケンスで、最初のパスはAS2にあり、最後のパスはAS1にあります。シーケンス内の各ASBRは、シーケンス内の前のASBRのBGPネクストホップです。
This reverse path information can be used to construct a unidirectional multicast distribution tree for VPLS X and VE-ID V, containing all the ASes that support X, and having PE1 at the root. We call such a tree an "inter-AS tree". Multicast data originating in VPLS sites for VPLS X connected to PE1 will travel downstream along the tree which is rooted at PE1.
この逆パス情報は、XをサポートするすべてのASを含み、ルートにPE1を持つ、VPLS XおよびVE-ID Vの単方向マルチキャスト配信ツリーを構築するために使用できます。このようなツリーを「AS間ツリー」と呼びます。 PE1に接続されているVPLS XのVPLSサイトで発信されたマルチキャストデータは、PE1をルートとするツリーに沿ってダウンストリームに移動します。
The path along an inter-AS tree is a sequence of ASBRs. It is still necessary to specify how the multicast data gets from a given ASBR to the set of ASBRs that are immediately downstream of the given ASBR along the tree. This is done by creating "segments". ASBRs in adjacent ASes will be connected by inter-AS segments; ASBRs in the same AS will be connected by "intra-AS segments".
AS間ツリーに沿ったパスは、ASBRのシーケンスです。ツリーに沿って特定のASBRのすぐ下流にある一連のASBRに、特定のASBRからマルチキャストデータを取得する方法を指定する必要があります。これは「セグメント」を作成することによって行われます。隣接するAS内のASBRは、AS間セグメントによって接続されます。同じAS内のASBRは、「AS内セグメント」によって接続されます。
For a given inter-AS tree and a given AS, there MUST be only one ASBR within that AS that accepts traffic flowing on that tree. Further, for a given inter-AS tree and a given AS, there MUST be only one ASBR in that AS that sends the traffic flowing on that tree to a particular adjacent AS. The precise rules for accomplishing this are given in subsequent sections.
特定のAS間ツリーとASの場合、そのAS内には、そのツリー上を流れるトラフィックを受け入れるASBRが1つだけ存在する必要があります。さらに、特定のAS間ツリーと特定のASの場合、そのASには、そのツリー上を流れるトラフィックを特定の隣接ASに送信するASBRが1つだけ存在する必要があります。これを実現するための正確なルールは、後続のセクションで説明されています。
An ASBR initiates creation of an intra-AS segment when the ASBR receives an Inter-AS A-D route from an External BGP (EBGP) neighbor. Creation of the segment is completed as a result of distributing, via IBGP, this route within the ASBR's own AS.
ASBRが外部BGP（EBGP）ネイバーからInter-AS A-Dルートを受信すると、ASBRはイントラASセグメントの作成を開始します。セグメントの作成は、IBBRを介して、ASBR自身のAS内でこのルートを配信した結果として完了します。
For a given inter-AS tunnel, each of its intra-AS segments could be constructed by its own independent mechanism. Moreover, by using upstream-assigned labels within a given AS, multiple intra-AS segments of different inter-AS tunnels of either the same or different VPLS instances may share the same P-multicast tree.
特定のAS間トンネルでは、AS内セグメントのそれぞれを独自の独立したメカニズムで構築できます。さらに、特定のAS内で上流に割り当てられたラベルを使用することにより、同じまたは異なるVPLSインスタンスの異なるAS間トンネルの複数のAS内セグメントが、同じPマルチキャストツリーを共有できます。
If the P-multicast tree instantiating a particular segment of an inter-AS tunnel is created by a multicast control protocol that uses receiver-initiated joins (e.g, mLDP), and this P-multicast tree does not aggregate multiple segments, then all the information needed to create that segment will be present in the Inter-AS A-D routes received by the ASBR from the neighboring ASBR. But if the P-multicast tree instantiating the segment is created by a protocol that does not use receiver-initiated joins (e.g., RSVP-TE, ingress unicast replication), or if this P-multicast tree aggregates multiple segments (irrespective of the multicast control protocol used to create the tree), then the ASBR needs to learn the leaves of the segment. These leaves are learned from A-D routes received from other PEs in the AS, for the same VPLS as the one to which the segment belongs.
AS間トンネルの特定のセグメントをインスタンス化するPマルチキャストツリーが、受信者が開始した結合（たとえば、mLDP）を使用するマルチキャスト制御プロトコルによって作成され、このPマルチキャストツリーが複数のセグメントを集約しない場合、そのセグメントの作成に必要な情報は、ASBRが隣接ASBRから受信したInter-AS ADルートに存在します。ただし、セグメントをインスタンス化するPマルチキャストツリーが、受信者が開始した結合を使用しないプロトコル（RSVP-TE、入力ユニキャストレプリケーションなど）によって作成された場合、またはこのPマルチキャストツリーが複数のセグメントを集約した場合（マルチキャストに関係なく）ツリーを作成するために使用される制御プロトコル）、ASBRはセグメントの葉を学習する必要があります。これらのリーフは、セグメントが属しているものと同じVPLSについて、ASの他のPEから受信したA-Dルートから学習されます。
The following sections specify procedures for propagation of Inter-AS A-D routes across ASes in order to construct inter-AS segmented trees.
次のセクションでは、AS間セグメント化ツリーを構築するために、AS間でのAS間A-Dルートの伝搬手順を指定します。
For a given VPLS configured on an ASBR when the ASBR receives Intra-AS A-D routes originated by PEs in its own AS, the ASBR MUST propagate each of these route in EBGP. This procedure MUST be performed for each of the VPLS instances configured on the ASBR. Each of these routes is constructed as follows:
ASBRが自身のAS内のPEから発信されたIntra-AS A-Dルートを受信するときにASBRで構成された特定のVPLSについて、ASBRはこれらのルートのそれぞれをEBGPで伝播する必要があります。この手順は、ASBRで構成された各VPLSインスタンスに対して実行する必要があります。これらのルートはそれぞれ次のように構成されています。
+ The route carries a single BGP VPLS A-D NLRI with the RD and VE-ID being the same as the NLRI in the received Intra-AS A-D route.
+ ルートは単一のBGP VPLS A-D NLRIを伝送し、RDとVE-IDは受信したIntra-AS A-DルートのNLRIと同じです。
+ The Next Hop field of the MP_REACH_NLRI attribute is set to a routable IP address of the ASBR.
+ MP_REACH_NLRI属性のNext Hopフィールドは、ASBRのルーティング可能なIPアドレスに設定されます。
+ The route carries the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication; the attribute carries no MPLS labels.
+ ルートは、トンネルタイプが入力レプリケーションに設定されたPMSIトンネル属性を伝送します。属性にはMPLSラベルがありません。
+ The route MUST carry the export RT used by the VPLS.
+ ルートは、VPLSで使用されるエクスポートRTを伝送する必要があります。
When an ASBR receives from one of its EBGP neighbors a BGP Update message that carries an Inter-AS A-D route, if (a) at least one of the RTs carried in the message matches one of the import RTs configured on the ASBR, and (b) the ASBR determines that the received route is the best route to the destination carried in the NLRI of the route, the ASBR re-advertises this Inter-AS A-D route to other PEs and ASBRs within its own AS. The best route selection procedures MUST ensure that for the same destination, all ASBRs in an AS pick the same route as the best route. The best route selection procedures are specified in [RFC4761] and clarified in [MULTI-HOMING]. The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP). This ASBR becomes the root of the intra-AS segment of the inter-AS tree and ensures that this is the only ASBR that accepts traffic into this AS from the inter-AS tree.
ASBRがそのEBGPネイバーの1つから受信した場合、（a）メッセージに含まれる少なくとも1つのRTがASBRに構成されているインポートRTの1つと一致する場合、Inter-AS ADルートを伝達するBGPアップデートメッセージ、および（ b）ASBRは、受信したルートがルートのNLRIで運ばれる宛先への最適なルートであると判断し、ASBRがこのInter-AS ADルートを自身のAS内の他のPEおよびASBRに再アドバタイズします。最適なルート選択手順では、同じ宛先に対して、AS内のすべてのASBRが同じルートを最適なルートとして選択するようにする必要があります。最良のルート選択手順は、[RFC4761]で指定され、[MULTI-HOMING]で明確にされています。最適なルート手順により、AS内の複数のASBRがEBGPネイバーから同じInter-AS A-Dルートを受信した場合、これらのASBRの1つだけがこのルートを内部BGP（IBGP）に伝搬します。このASBRは、AS間ツリーのAS内セグメントのルートになり、これがAS間ツリーからこのASへのトラフィックを受け入れる唯一のASBRであることを保証します。
When re-advertising an Inter-AS A-D route, the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR.
Inter-AS A-Dルートを再アドバタイズするとき、ASBRはMP_REACH_NLRI属性のNext HopフィールドをASBRのルーティング可能なIPアドレスに設定する必要があります。
Depending on the type of a P-multicast tunnel used to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of the re-advertised Inter-AS A-D route is constructed as follows:
AS間トンネルのAS内セグメントのインスタンス化に使用されるPマルチキャストトンネルのタイプに応じて、再アドバタイズされたAS間A-DルートのPMSIトンネル属性は次のように構築されます。
+ If the ASBR uses ingress replication to instantiate the intra-AS segment of the inter-AS tunnel, the re-advertised route MUST NOT carry the PMSI Tunnel attribute.
+ ASBRが入力レプリケーションを使用してAS間トンネルのAS内セグメントをインスタンス化する場合、再アドバタイズされたルートはPMSIトンネル属性を伝送してはなりません（MUST NOT）。
+ If the ASBR uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree that is used to instantiate the segment (note that the ASBR could create the identity of the tree prior to the actual instantiation of the segment). If, in order to instantiate the segment, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the A-D routes received from other PEs/ASBRs in the ASBR's own AS.
+ ASBRがPマルチキャストツリーを使用してAS間トンネルのAS内セグメントをインスタンス化する場合、PMSIトンネル属性には、セグメントのインスタンス化に使用されるツリーのIDが含まれている必要があります（ASBRがIDを作成できることに注意してください）セグメントの実際のインスタンス化の前のツリーの）。セグメントをインスタンス化するために、ASBRがツリーの葉を知る必要がある場合、ASBRは、ASBR自身のAS内の他のPE / ASBRから受信したA-Dルートからこの情報を取得します。
+ An ASBR that uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel MAY aggregate two or more VPLS instances present on the ASBR onto the same tree. If the ASBR already advertises Inter-AS A-D routes for these VPLS instances, then aggregation requires the ASBR to re-advertise these routes.
+ Pマルチキャストツリーを使用してAS間トンネルのAS内セグメントをインスタンス化するASBRは、ASBRに存在する2つ以上のVPLSインスタンスを同じツリーに集約できます（MAY）。 ASBRがこれらのVPLSインスタンスのInter-AS A-Dルートをすでにアドバタイズしている場合、集約ではASBRがこれらのルートを再アドバタイズする必要があります。
The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the ASBR has not previously advertised Inter-AS A-D routes for these VPLS instances, then the aggregation requires the ASBR to advertise (new) Inter-AS A-D routes for these VPLS instances. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the VPLS instances, as well as an MPLS upstream-assigned label [RFC5331]. Each newly advertised or re-advertised route MUST have a label that is distinct within the scope of the ASBR.
再アドバタイズされたルートは、PMSIトンネル属性を除いて、元のルートと同じである必要があります。 ASBRが以前にこれらのVPLSインスタンスのInter-AS A-Dルートをアドバタイズしていない場合、集約では、ASBRがこれらのVPLSインスタンスの（新しい）Inter-AS A-Dルートをアドバタイズする必要があります。新しくアドバタイズ/再アドバタイズされたルートのPMSIトンネル属性は、VPLSインスタンスを集約するPマルチキャストツリーのIDと、MPLSアップストリーム割り当てラベル[RFC5331]を運ぶ必要があります。新たにアドバタイズまたは再アドバタイズされた各ルートには、ASBRのスコープ内で異なるラベルが必要です。
In addition, the ASBR MUST send to the EBGP neighbor, from whom it receives the Inter-AS A-D route, a BGP Update message that carries a leaf A-D route. The exact encoding of this route is described in the "BGP Extensions" section. This route contains the following information elements:
さらに、ASBRは、AS-Inter A-Dルートを受信するEBGPネイバーにリーフA-Dルートを運ぶBGPアップデートメッセージを送信する必要があります。このルートの正確なエンコーディングについては、「BGP拡張」セクションで説明しています。このルートには、次の情報要素が含まれています。
+ The route carries a single NLRI with the Route Key field set to the <RD, VE-ID> tuple of the BGP VPLS A-D NLRI of the Inter-AS A-D route received from the EBGP neighbor. The NLRI also carries the IP address of the ASBR (this MUST be a routable IP address).
+ このルートは、EBGPネイバーから受信したInter-AS A-DルートのBGP VPLS A-D NLRIの<RD、VE-ID>タプルに設定されたルートキーフィールドを持つ単一のNLRIを伝送します。 NLRIはASBRのIPアドレスも伝送します（これはルーティング可能なIPアドレスでなければなりません）。
+ The leaf A-D route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, and the Tunnel Identifier set to a routable address of the advertising router. The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used to demultiplex the VPLS traffic received over a unicast tunnel by the advertising router.
+ リーフA-Dルートには、トンネルタイプがIngress Replicationに設定されたPMSIトンネル属性と、広告ルーターのルーティング可能なアドレスに設定されたトンネル識別子を含める必要があります。 PMSIトンネル属性は、通知ルーターによってユニキャストトンネルを介して受信されたVPLSトラフィックを逆多重化するために使用されるダウンストリーム割り当てMPLSラベルを運ぶ必要があります。
+ 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 the distribution scope of this route, the route MUST carry the NO_ADVERTISE BGP Community ([RFC1997]).
+ このルートの配信範囲を制限するために、ルートはNO_ADVERTISE BGPコミュニティ（[RFC1997]）を運ぶ必要があります。
+ The ASBR constructs an IP-address-specific RT by placing the IP address carried in the Next Hop field of the received Inter-AS VPLS A-D route in the Global Administrator field of the community, with the Local Administrator field of this community set to 0. It also sets the Extended Communities attribute of the leaf A-D route to that community. Note that this RT is the same as the ASBR Import RT of the EBGP neighbor from which the ASBR received the Inter-AS VPLS A-D route.
+ ASBRは、受信したInter-AS VPLS ADルートのNext Hopフィールドに含まれるIPアドレスをコミュニティのGlobal Administratorフィールドに配置し、このコミュニティのLocal Administratorフィールドを0に設定して、IPアドレス固有のRTを構築します。また、そのコミュニティへのリーフADルートの拡張コミュニティ属性を設定します。このRTは、ASBRがInter-AS VPLS A-Dルートを受信したEBGPネイバーのASBRインポートRTと同じであることに注意してください。
When an ASBR receives, via EBGP, a leaf A-D route, the ASBR accepts the route only if (a) at least one of the RTs carried in the message matches one of the import RTs configured on the ASBR and (b) the ASBR determines that the received route is the best route to the destination carried in the NLRI of the route.
ASBRがEBGPを介してリーフADルートを受信すると、ASBRは、（a）メッセージに含まれる少なくとも1つのRTがASBRで構成されたインポートRTの1つと一致し、（b）ASBRが決定した場合にのみルートを受け入れます受信したルートが、ルートのNLRIで運ばれる宛先への最良のルートであること。
If the ASBR accepts the leaf A-D route, the ASBR looks for an existing A-D route whose BGP-VPLS A-D NLRI has the same value as the <RD, VE-ID> field of the leaf A-D route just accepted. If such an A-D route is found, then the MPLS label carried in the PMSI Tunnel attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR LSP to the tail of the intra-AS tunnel segment associated with the found A-D route.
ASBRがリーフA-Dルートを受け入れる場合、ASBRは、BGP-VPLS A-D NLRIが、受け入れられたリーフA-Dルートの<RD、VE-ID>フィールドと同じ値を持つ既存のA-Dルートを探します。そのようなADルートが見つかった場合、リーフADルートのPMSIトンネル属性に含まれるMPLSラベルを使用して、見つかったADルートに関連付けられたAS内トンネルセグメントの末尾に1ホップASBR-ASBR LSPをステッチします。 。
In the context of this section, we use the term "PE/ASBR router" to denote either a PE or an ASBR router.
このセクションのコンテキストでは、「PE / ASBRルーター」という用語を使用して、PEまたはASBRルーターを示します。
Note that a given Inter-AS A-D route is advertised within a given AS by only one ASBR, as described above.
上記のように、特定のInter-AS A-Dルートは、特定のAS内で1つのASBRだけによってアドバタイズされることに注意してください。
When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP Update message that carries an Inter-AS A-D route, if (a) at least one of the RTs carried in the message matches one of the import RTs configured on the PE/ASBR and (b) the PE/ASBR determines that the received route is the best route to the destination carried in the NLRI of the route, the PE/ASBR performs the following operations. The best route determination is as described in [RFC4761] and clarified in [MULTI-HOMING].
PE / ASBRルーターがそのIBGPネイバーの1つから受信した場合、（a）メッセージに含まれるRTの少なくとも1つが、構成されているインポートRTの1つと一致する場合、AS間ADルートを運ぶBGP更新メッセージPE / ASBRおよび（b）PE / ASBRは、受信したルートがルートのNLRIで運ばれる宛先への最良のルートであると判断した場合、PE / ASBRは次の操作を実行します。最適なルートの決定は、[RFC4761]で説明されており、[MULTI-HOMING]で明確化されています。
If the router is an ASBR, then the ASBR propagates the route to its EBGP neighbors. When propagating the route to the EBGP neighbors, the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR.
ルータがASBRの場合、ASBRはルートをEBGPネイバーに伝播します。 EBGPネイバーへのルートを伝播するとき、ASBRはMP_REACH_NLRI属性のNext HopフィールドをASBRのルーティング可能なIPアドレスに設定する必要があります。
If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the P-multicast tree whose identity is carried in the PMSI Tunnel attribute.
受信したInter-AS A-Dルートが、トンネルタイプがLDP P2MP LSPに設定されたPMSIトンネル属性を伝送する場合、PE / ASBRは、そのアイデンティティがPMSIトンネル属性で伝送されるPマルチキャストツリーに参加する必要があります（SHOULD）。
If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSP MAY have been established before the local PE/ASBR receives the route, or it MAY be established after the local PE receives the route.
受信したInter-AS A-Dルートが、トンネル識別子がRSVP-TE P2MP LSPに設定されたPMSIトンネル属性を運ぶ場合、ルートを発信したASBRは、ローカルPE / ASBRをリーフとしてRSVP-TE P2MP LSPを確立する必要があります。このLSPは、ローカルPE / ASBRがルートを受信する前に確立されている場合と、ローカルPEがルートを受信した後に確立されている場合があります。
If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, but the attribute does not carry a label, then the P-multicast tree, as identified by the PMSI Tunnel attribute, is an intra-AS LSP segment that is part of the inter-AS tunnel for the <VPLS, VE-ID> advertised by the Inter-AS A-D route and rooted at the PE that originated the A-D route. If the PMSI Tunnel attribute carries a (upstream-assigned) label, then a combination of this tree and the label identifies the intra-AS segment. If the receiving router is an ASBR, this intra-AS segment may further be stitched to ASBR-ASBR inter-AS segment of the inter-AS tunnel. If the PE/ASBR has local receivers in the VPLS, packets received over the intra-AS segment must be forwarded to the local receivers using the local VSI.
受信したInter-AS ADルートが、トンネルタイプがLDP P2MP LSPまたはRSVP-TE P2MP LSPに設定されたPMSIトンネル属性を運ぶが、属性がラベルを持たない場合、P-マルチキャストツリーは、 PMSIトンネル属性は、Inter-AS ADルートによってアドバタイズされ、ADルートを発信したPEをルートとする<VPLS、VE-ID>のInter-ASトンネルの一部であるAS内LSPセグメントです。 PMSIトンネル属性に（アップストリーム割り当て）ラベルが付いている場合、このツリーとラベルの組み合わせにより、AS内セグメントが識別されます。受信ルーターがASBRの場合、このAS内セグメントは、AS間トンネルのASBR-ASBR AS間セグメントにさらにステッチされます。 PE / ASBRのVPLSにローカルレシーバーがある場合、AS内セグメントを介して受信したパケットは、ローカルVSIを使用してローカルレシーバーに転送する必要があります。
In this model, there is a multi-hop EBGP peering between the PEs (or BGP Route Reflector) in one AS and the PEs (or BGP Route Reflector) in another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI, along with the PMSI Tunnel attribute, as in the intra-AS case described in the "Demultiplexing P-Multicast Tree Traffic" section.
このモデルでは、あるASのPE（またはBGPルートリフレクター）と別のASのPE（またはBGPルートリフレクター）の間にマルチホップEBGPピアリングがあります。 「Pマルチキャストツリートラフィックの逆多重化」で説明したAS内の場合と同様に、PEはBSI-VPLS NLRIまたはBGP-VPLS A-D NLRIとPMSIトンネル属性を交換します。
The PEs in different ASes use a non-segmented inter-AS P2MP tunnel for VPLS multicast. A non-segmented inter-AS tunnel is a single tunnel that spans AS boundaries. The tunnel technology cannot change from one point in the tunnel to the next, so all ASes through which the tunnel passes must support that technology. In essence, AS boundaries are of no significance to a non-segmented inter-AS P2MP tunnel.
異なるASのPEは、VPLSマルチキャストに非セグメント化AS間P2MPトンネルを使用します。非セグメント化AS間トンネルは、AS境界にまたがる単一のトンネルです。トンネルテクノロジーはトンネル内のあるポイントから次のポイントに変更できないため、トンネルが通過するすべてのASがそのテクノロジーをサポートする必要があります。本質的に、AS境界は、セグメント化されていないAS間P2MPトンネルにとって重要ではありません。
This model requires no VPLS A-D routes in the control plane or VPLS MAC address learning in the data plane on the ASBRs. The ASBRs only need to participate in the non-segmented P2MP tunnel setup in the control plane and do MPLS label forwarding in the data plane.
このモデルでは、コントロールプレーンでのVPLS A-Dルート、またはASBRのデータプレーンでのVPLS MACアドレス学習は必要ありません。 ASBRは、コントロールプレーンのセグメント化されていないP2MPトンネルセットアップに参加し、データプレーンでMPLSラベル転送を行うだけです。
When the tunneling technology is P2MP LSP signaled with mLDP, and one does not use [RFC6512], the setup of non-segmented inter-AS P2MP tunnels requires the P-routers in one AS to have IP reachability to the loopback addresses of the PE routers in another AS. That is, the reachability to the loopback addresses of PE routers in one AS MUST be present in the IGP in another AS.
トンネリングテクノロジーがmLDPでシグナリングされたP2MP LSPであり、[RFC6512]を使用しない場合、非セグメント化されたAS間P2MPトンネルのセットアップでは、1つのASのPルーターがPEのループバックアドレスにIP到達可能である必要があります。別のAS内のルーター。つまり、あるASのPEルータのループバックアドレスへの到達可能性は、別のASのIGPに存在する必要があります。
The data forwarding in this model is the same as in the intra-AS case described in the "Demultiplexing P-Multicast Tree Traffic" section.
このモデルのデータ転送は、「Pマルチキャストツリートラフィックの逆多重化」で説明したAS内の場合と同じです。
An implementation MUST support this model.
実装はこのモデルをサポートする必要があります。
Whenever a particular multicast stream is being sent on an Inclusive P-multicast tree, it is likely that the data of that stream is being sent to PEs that do not require it, as the sites connected to these PEs may have no receivers for the stream. If a particular stream has a significant amount of traffic, it may be beneficial to move it to a Selective P-multicast tree that has, at its leaves, only those PEs, connected to sites that have receivers for the multicast stream (or at least includes fewer PEs that are attached to sites with no receivers compared to an Inclusive tree).
特定のマルチキャストストリームが包含的Pマルチキャストツリーで送信されているときは常に、そのストリームのデータは、それを必要としないPEに送信されている可能性があります。これらのPEに接続されたサイトには、ストリームのレシーバーがない可能性があるためです。 。特定のストリームに大量のトラフィックがある場合は、そのストリームを、そのリーフで、マルチキャストストリームのレシーバーがあるサイトに接続されているPEのみに接続している選択的Pマルチキャストツリーに移動することをお勧めします（または少なくとも包含ツリーと比較して、レシーバーのないサイトに接続されているPEの数が少ない）。
A PE connected to the multicast source of a particular multicast stream may be performing explicit tracking; that is, it may know the PEs that have receivers in the multicast stream. The "Receiving S-PMSI A-D Routes by PEs" section describes procedures that enable explicit tracking. If this is the case, Selective P-multicast trees can also be triggered on other criteria. For instance, there could be a "pseudo-wasted bandwidth" criterion: switching to a Selective tree would be done if the bandwidth multiplied by the number of "uninterested" PEs (PEs that are receiving the stream but have no receivers) is above a specified threshold. The motivation is that (a) the total bandwidth wasted by many sparsely subscribed low- bandwidth groups may be large and (b) there's no point to moving a high-bandwidth group to a Selective tree if all the PEs have receivers for it.
特定のマルチキャストストリームのマルチキャストソースに接続されたPEが明示的な追跡を実行している可能性があります。つまり、マルチキャストストリームにレシーバーがあるPEを知っている可能性があります。 「PEによるS-PMSI A-Dルートの受信」では、明示的な追跡を有効にする手順について説明します。この場合、他の基準で選択的Pマルチキャストツリーをトリガーすることもできます。たとえば、「疑わしい無駄な帯域幅」の基準が存在する可能性があります。「関心のない」PE（ストリームを受信しているが受信機がないPE）の数を帯域幅に掛けると、選択ツリーに切り替わります。指定されたしきい値。その動機は、（a）多くのまばらにサブスクライブされた低帯域幅グループによって浪費される合計帯域幅が大きくなる可能性があること、および（b）すべてのPEにレシーバーがある場合、高帯域幅グループを選択ツリーに移動する意味がないことです。
Switching a (C-S, C-G) stream to a Selective P-multicast tree may require the root of the tree to determine the egress PEs that need to receive the (C-S, C-G) traffic. This is true in the following cases:
（C-S、C-G）ストリームを選択的Pマルチキャストツリーに切り替えるには、（C-S、C-G）トラフィックを受信する必要がある出力PEを決定するためにツリーのルートが必要になる場合があります。これは、次の場合に当てはまります。
+ If the tunnel is a P2MP tree, such as an RSVP-TE P2MP Tunnel, the PE needs to know the leaves of the tree before it can instantiate the Selective tree.
+ トンネルがRSVP-TE P2MPトンネルなどのP2MPツリーである場合、選択ツリーをインスタンス化する前に、PEはツリーの葉を知る必要があります。
+ If a PE decides to send traffic for multicast streams, belonging to different VPLS instances, using one P-multicast Selective tree, such a tree is called an "Aggregate tree with a selective mapping". The setting up of such an Aggregate tree requires the ingress PE to know all the other PEs that have receivers for multicast groups that are mapped onto the tree (see the "Aggregation Considerations" section for the rationale).
+ PEが1つのPマルチキャスト選択ツリーを使用して、異なるVPLSインスタンスに属するマルチキャストストリームのトラフィックを送信することを決定した場合、そのようなツリーは「選択的マッピングを使用した集約ツリー」と呼ばれます。このような集約ツリーを設定するには、ツリーにマップされているマルチキャストグループのレシーバーを持つ他のすべてのPEを入力PEが知っている必要があります（根拠については、「集約に関する考慮事項」を参照してください）。
+ If ingress replication is used and the ingress PE wants to send traffic for (C-S, C-G)s to only those PEs that are on the path to receivers to the (C-S, C-G)s.
+ 入力レプリケーションが使用され、入力PEが（C-S、C-G）のレシーバーへのパス上にあるPEのみに（C-S、C-G）のトラフィックを送信したい場合。
For discovering the IP multicast group membership, for the above cases, this document describes procedures that allow an ingress PE to enable explicit tracking. Thus, an ingress PE can request the IP multicast membership from egress PEs for one or more C-multicast streams. These procedures are described in the "Receiving S-PMSI A-D Routes by PEs" section.
このドキュメントでは、IPマルチキャストグループメンバーシップを検出するために、上記のケースについて、入力PEで明示的な追跡を有効にする手順について説明します。したがって、入力PEは、1つ以上のCマルチキャストストリームについて、出力PEからのIPマルチキャストメンバーシップを要求できます。これらの手順については、「PEによるS-PMSI A-Dルートの受信」で説明しています。
The root of the Selective P-multicast tree MAY decide to do explicit tracking of the IP multicast stream only after it has decided to move the stream to a Selective tree, or it MAY have been doing explicit tracking all along. This document also describes explicit tracking for a wildcard source and/or group in the "Receiving S-PMSI A-D Routes by PEs" section, which facilitates a Selective P-multicast tree only mode in which IP multicast streams are always carried on a Selective P-multicast tree. In the description on Selective P-multicast trees, the notation C-S is intended to represent either a specific source address or a wildcard. Similarly, C-G is intended to represent either a specific group address or a wildcard.
選択的Pマルチキャストツリーのルートは、IPマルチキャストストリームを明示的に追跡することを決定する場合があります。これは、ストリームを選択的ツリーに移動することを決定した後、または明示的に追跡を行っている場合があります。このドキュメントでは、「PEによるS-PMSI ADルートの受信」セクションでワイルドカードソースやグループの明示的な追跡についても説明しています。これにより、IPマルチキャストストリームが常に選択的Pで伝送される選択的P-マルチキャストツリーのみのモードが容易になります。 -マルチキャストツリー。選択的Pマルチキャストツリーの説明では、C-Sという表記は、特定の送信元アドレスまたはワイルドカードを表すことを目的としています。同様に、C-Gは特定のグループアドレスまたはワイルドカードを表すことを目的としています。
The PE at the root of the tree MUST signal the leaves of the tree that the (C-S, C-G) stream is now bound to the Selective tree. Note that the PE could create the identity of the P-multicast tree prior to the actual instantiation of the tunnel.
ツリーのルートにあるPEは、（C-S、C-G）ストリームが現在選択ツリーにバインドされていることをツリーの葉に通知する必要があります。 PEは、トンネルの実際のインスタンス化の前にPマルチキャストツリーのIDを作成できることに注意してください。
If the Selective tree is instantiated by an RSVP-TE P2MP LSP, the PE at the root of the tree MUST establish the P2MP RSVP-TE LSP to the leaves. This LSP MAY have been established before the leaves receive the Selective tree binding, or it MAY be established after the leaves receive the binding. A leaf MUST NOT switch to the Selective tree until it receives the binding and the RSVP-TE P2MP LSP is set up to the leaf.
選択ツリーがRSVP-TE P2MP LSPによってインスタンス化される場合、ツリーのルートにあるPEは、リーフへのP2MP RSVP-TE LSPを確立する必要があります。このLSPは、葉が選択的ツリーバインディングを受信する前に確立される場合があります。または、葉がバインディングを受信した後に確立される場合があります。葉はバインディングを受信し、RSVP-TE P2MP LSPが葉に設定されるまで、選択ツリーに切り替えてはなりません（MUST NOT）。
Selective trees provide a PE the ability to create separate P-multicast trees for certain (C-S, C-G) streams. The source PE, which originates the Selective tree, and the egress PEs MUST use the Selective tree for the (C-S, C-G) streams that are mapped to it. This may require the source and egress PEs to switch to the Selective tree from an Inclusive tree if they were already using an Inclusive tree for the (C-S, C-G) streams mapped to the Selective tree.
選択的ツリーは、特定の（C-S、C-G）ストリームに対して個別のPマルチキャストツリーを作成する機能をPEに提供します。選択ツリーを発信するソースPE、および出力PEは、それにマップされている（C-S、C-G）ストリームに選択ツリーを使用する必要があります。選択ツリーにマップされた（C-S、C-G）ストリームに包含ツリーをすでに使用している場合、ソースPEと出力PEが包含ツリーから選択ツリーに切り替える必要があります。
Once a source PE decides to set up a Selective tree, it MUST announce the mapping of the (C-S, C-G) streams (which may be in different VPLS instances) that are mapped to the tree to the other PEs using BGP. After the egress PEs receive the announcement, they set up their forwarding path to receive traffic on the Selective tree if they have one or more receivers interested in the (C-S, C-G) streams mapped to the tree. Setting up the forwarding path requires setting up the demultiplexing forwarding entries based on the top MPLS label (if there is no inner label) or the inner label (if present) as described in the "Establishing P-Multicast Trees" section.
ソースPEが選択ツリーをセットアップすることを決定したら、BGPを使用してツリーにマップされている（C-S、C-G）ストリーム（異なるVPLSインスタンスにある場合があります）のマッピングを他のPEに通知する必要があります。出力PEはアナウンスを受信した後、（C-S、C-G）ストリームに関係する1つ以上のレシーバーがツリーにマップされている場合、選択的ツリーでトラフィックを受信するように転送パスを設定します。転送パスを設定するには、「Pマルチキャストツリーの確立」の説明に従って、最上位MPLSラベル（内部ラベルがない場合）または内部ラベル（存在する場合）に基づいて、逆多重化転送エントリを設定する必要があります。
When the P2MP LSP is established using mLDP, the egress PEs MAY perform this switch to the Selective tree once the announcement from the ingress PE is received, or they MAY wait for a preconfigured timer to do so after receiving the announcement.
mLDPを使用してP2MP LSPが確立されると、出力PEは、入力PEからのアナウンスが受信されると、選択ツリーに対してこの切り替えを実行するか、アナウンスの受信後に事前設定されたタイマーがそれを行うのを待つ場合があります。
When the P2MP LSP protocol is P2MP RSVP-TE, an egress PE MUST perform this switch to the Selective tree only after the announcement from the ingress PE is received and the RSVP-TE P2MP LSP has been set up to the egress PE. This switch MAY be done after waiting for a preconfigured timer after these two steps have been accomplished.
P2MP LSPプロトコルがP2MP RSVP-TEの場合、出力PEは、入力PEからのアナウンスが受信され、RSVP-TE P2MP LSPが出力PEに設定された後にのみ、選択ツリーへの切り替えを実行する必要があります。この切り替えは、これらの2つのステップが完了した後、事前設定されたタイマーを待ってから行うことができます。
A source PE MUST use the following approach to decide when to start transmitting data on the Selective tree, if it is currently using an Inclusive tree. After announcing the (C-S, C-G) stream mapping to a Selective tree, the source PE MUST wait for a "switchover" delay before sending (C-S, C-G) stream on the Selective tree. It is RECOMMENDED to allow this delay to be configurable. Once the
ソースPEは、次のアプローチを使用して、現在選択的ツリーを使用している場合に、選択的ツリーでデータの送信を開始するタイミングを決定する必要があります。 （C-S、C-G）ストリームマッピングを選択ツリーにアナウンスした後、ソースPEは、選択ツリーで（C-S、C-G）ストリームを送信する前に、「スイッチオーバー」遅延を待機する必要があります。この遅延を構成可能にすることをお勧めします。一度
"switchover" delay has elapsed, the source PE MUST send (C-S, C-G) stream on the Selective tree. In no case is any (C-S, C-G) packet sent on both Selective and Inclusive trees.
「切り替え」遅延が経過した場合、ソースPEは選択ツリーで（C-S、C-G）ストリームを送信する必要があります。選択的ツリーと包含的ツリーの両方で送信される（C-S、C-G）パケットはありません。
When a (C-S, C-G) stream is switched from an Inclusive to a Selective tree, the purpose of running a switchover timer is to minimize packet loss without introducing packet duplication. However, jitter may be introduced due to the difference in transit delays between the Inclusive and Selective trees.
（C-S、C-G）ストリームが包括的ツリーから選択的ツリーに切り替えられる場合、スイッチオーバータイマーを実行する目的は、パケットの重複を招くことなくパケット損失を最小限に抑えることです。ただし、包括的ツリーと選択的ツリーの通過遅延の違いにより、ジッタが発生する可能性があります。
For best effect, the switchover timer should be configured to a value that is "just long enough" (a) to allow all the PEs to learn about the new binding of (C-S, C-G) to a Selective tree and (b) to allow the PEs to construct the P-tunnel associated with the Selective tree, if it doesn't already exist.
最良の効果を得るには、スイッチオーバータイマーを「十分に長い」値に設定する必要があります。（a）すべてのPEが（CS、CG）の選択ツリーへの新しいバインディングについて学習できるようにし、（b）選択ツリーに関連付けられているPトンネルを構築するPE（まだ存在しない場合）。
The ingress PE informs all the PEs that are on the path to receivers of the (C-S, C-G) of the binding of the Selective tree to the (C-S, C-G), using BGP. The BGP announcement is done by sending update for the MCAST-VPLS address family using what we referred to as an "S-PMSI A-D route". The format of the NLRI of this route is described in the "Inclusive Tree/Selective Tree Identifier" section. The NLRI MUST be constructed as follows:
入力PEは、BGPを使用して、（C-S、C-G）への選択ツリーのバインディングを（C-S、C-G）のレシーバーへのパス上にあるすべてのPEに通知します。 BGPアナウンスは、「S-PMSI A-Dルート」と呼ばれるものを使用して、MCAST-VPLSアドレスファミリの更新を送信することによって行われます。このルートのNLRIの形式については、「包含ツリー/選択的ツリー識別子」セクションで説明しています。 NLRIは次のように構築する必要があります。
+ The Route Distinguisher (RD) MUST be set to the RD configured locally for the VPLS. This is required to uniquely identify the <C-S, C-G> as the addresses could overlap between different VPLS instances. This MUST be the same RD value used in the VPLS auto-discovery process.
+ Route Distinguisher（RD）は、VPLS用にローカルに構成されたRDに設定する必要があります。異なるVPLSインスタンス間でアドレスが重複する可能性があるため、<C-S、C-G>を一意に識別するために必要です。これは、VPLS自動検出プロセスで使用されるのと同じRD値でなければなりません。
+ The Multicast Source field MUST contain the source address associated with the C-multicast stream, and the Multicast Source Length field is set appropriately to reflect this. If the source address is a wildcard, the source address is set to 0.
+ Multicast Sourceフィールドには、Cマルチキャストストリームに関連付けられたソースアドレスを含める必要があり、Multicast Source Lengthフィールドは、これを反映するように適切に設定されます。送信元アドレスがワイルドカードの場合、送信元アドレスは0に設定されます。
+ The Multicast Group field MUST contain the group address associated with the C-multicast stream, and the Multicast Group Length field is set appropriately to reflect this. If the group address is a wildcard, the group address is set to 0.
+ マルチキャストグループフィールドには、Cマルチキャストストリームに関連付けられたグループアドレスを含める必要があります。マルチキャストグループ長フィールドは、これを反映するように適切に設定されます。グループアドレスがワイルドカードの場合、グループアドレスは0に設定されます。
+ The Originating Router's IP Address field MUST be set to the IP address that the (local) PE places in the BGP Next Hop of the BGP-VPLS A-D routes. Note that the <RD, Originating Router's IP Address> tuple uniquely identifies a given VPLS instance on a PE.
+ 発信元ルーターのIPアドレスフィールドは、（ローカル）PEがBGP-VPLS A-DルートのBGPネクストホップに配置するIPアドレスに設定する必要があります。 <RD、発信元ルーターのIPアドレス>タプルは、PE上の特定のVPLSインスタンスを一意に識別することに注意してください。
The PE constructs the rest of the Selective A-D route as follows.
PEは残りの選択的A-Dルートを次のように構築します。
Depending on the type of a P-multicast tree used for the P-tunnel, the PMSI Tunnel attribute of the S-PMSI A-D route is constructed as follows:
Pトンネルに使用されるPマルチキャストツリーのタイプに応じて、S-PMSI A-DルートのPMSIトンネル属性は次のように構築されます。
+ The PMSI Tunnel attribute MUST contain the identity of the P-multicast tree (note that the PE could create the identity of the tree prior to the actual instantiation of the tree).
+ PMSIトンネル属性には、PマルチキャストツリーのIDが含まれている必要があります（PEは、ツリーの実際のインスタンス化の前に、ツリーのIDを作成できることに注意してください）。
+ If, in order to establish the P-multicast tree, the PE needs to know the leaves of the tree within its own AS, then the PE obtains this information from the leaf A-D routes received from other PEs/ASBRs within its own AS (as other PEs/ASBRs originate leaf A-D routes in response to receiving the S-PMSI A-D route) by setting the Leaf Information Required flag in the PMSI Tunnel attribute to 1. This enables explicit tracking for the multicast stream(s) advertised by the S-PMSI A-D route.
+ Pマルチキャストツリーを確立するために、PEが自身のAS内のツリーのリーフを知る必要がある場合、PEは、自身のAS内の他のPE / ASBRから受信したリーフADルートからこの情報を取得します（他のPE / ASBRは、S-PMSI ADルートの受信に応答してリーフADルートを発信します）。これには、PMSIトンネル属性のリーフ情報必須フラグを1に設定します。これにより、S- PMSI ADルート。
+ If a PE originates S-PMSI A-D routes with the Leaf Information Required flag in the PMSI Tunnel attribute set to 1, then the PE MUST be (auto-)configured with an import RT, which controls acceptance of leaf A-D routes by the PE. (Procedures for originating leaf A-D routes by the PEs that receive the S-PMSI A-D route are described in the "Receiving S-PMSI A-D Routes by PEs" section.)
+ PEがPMSIトンネル属性のLeaf Information Requiredフラグを1に設定してS-PMSI A-Dルートを発信する場合、PEは、PEによるリーフA-Dルートの受け入れを制御するインポートRTで（自動）構成する必要があります。 （S-PMSI A-Dルートを受信するPEがリーフA-Dルートを発信する手順については、「PEによるS-PMSI A-Dルートの受信」を参照してください）。
This RT is IP address specific. The Global Administrator field of this RT MUST be set to the IP address carried in the Next Hop field of all the S-PMSI A-D routes advertised by this PE (if the PE uses different Next Hop fields, then the PE MUST be (auto-)configured with multiple import RTs, one per each such Next Hop field). The Local Administrator field of this Route Target MUST be set to 0.
このRTはIPアドレス固有です。このRTのグローバル管理者フィールドは、このPEによってアドバタイズされるすべてのS-PMSI ADルートの次ホップフィールドで運ばれるIPアドレスに設定する必要があります（PEが別の次ホップフィールドを使用する場合、PEは（自動）複数のインポートRTで構成され、そのようなNext Hopフィールドごとに1つ）。このルートターゲットのローカル管理者フィールドは0に設定する必要があります。
If the PE supports Route Target Constrain [RFC4684], the PE SHOULD advertise this import RT within its own AS using Route Target Constrain. To constrain distribution of the Route Target Constrain routes to the AS of the advertising PE these routes SHOULD carry the NO_EXPORT Community ([RFC1997]).
PEがルートターゲット制約[RFC4684]をサポートしている場合、PEはルートターゲット制約を使用して、自身のAS内でこのインポートRTをアドバタイズする必要があります。 Route Target Constrainルートの配布をアドバタイジングPEのASに制限するには、これらのルートはNO_EXPORTコミュニティ（[RFC1997]）を伝送する必要があります（SHOULD）。
+ A PE MAY aggregate two or more S-PMSIs originated by the PE onto the same P-multicast tree. If the PE already advertises S-PMSI A-D routes for these S-PMSIs, then aggregation requires the PE to re-advertise these routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised S-PMSI A-D routes for these S-PMSIs, then the aggregation requires the PE to advertise (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the S-PMSIs. If at least some of the S-PMSIs aggregated onto the same P-multicast tree belong to different VPLS instances, then all these routes MUST carry an MPLS upstream-assigned label [RFC5331]. If all these aggregated S-PMSIs belong to the same VPLS, then the routes MAY carry an MPLS upstream-assigned label [RFC5331]. The labels MUST be distinct on a per-VPLS-instance basis, and they MAY be distinct on a per-route basis.
+ PEは、PEによって発信された2つ以上のS-PMSIを同じPマルチキャストツリーに集約できます（MAY）。 PEがすでにこれらのS-PMSIのS-PMSI A-Dルートをアドバタイズしている場合、アグリゲーションではPEがこれらのルートを再アドバタイズする必要があります。再アドバタイズされたルートは、PMSIトンネル属性を除いて、元のルートと同じである必要があります。 PEが以前にこれらのS-PMSIのS-PMSI A-Dルートをアドバタイズしていない場合、集約では、PEがこれらのS-PMSIの（新しい）S-PMSI A-Dルートをアドバタイズする必要があります。新たにアドバタイズ/再アドバタイズされたルートのPMSIトンネル属性は、S-PMSIを集約するPマルチキャストツリーのIDを運ぶ必要があります。同じPマルチキャストツリーに集約されたS-PMSIの少なくとも一部が異なるVPLSインスタンスに属している場合、これらすべてのルートはMPLSアップストリーム割り当てラベル[RFC5331]を伝達する必要があります。これらすべての集約されたS-PMSIが同じVPLSに属している場合、ルートはMPLSアップストリーム割り当てラベル[RFC5331]を運ぶことができます（MAY）。ラベルは、VPLSインスタンスごとに区別する必要があり、ルートごとに区別する必要があります。
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.
ルートのMP_REACH_NLRI属性の次ホップフィールドは、発信元ルーターのIPアドレスフィールドで運ばれるものと同じIPアドレスに設定する必要があります（SHOULD）。
By default, the set of RTs carried by the route MUST be the same as the RTs carried in the BGP-VPLS A-D route originated from the VSI. The default could be modified via configuration.
デフォルトでは、ルートによって運ばれるRTのセットは、VSIから発信されたBGP-VPLS A-Dルートで運ばれるRTと同じである必要があります。デフォルトは設定を介して変更できます。
Consider a PE that receives an S-PMSI A-D route. If one or more of the VSIs on the PE have their import RTs that contain one or more of the RTs carried by the received S-PMSI A-D route, then for each such VSI, the PE performs the following.
S-PMSI A-Dルートを受信するPEについて考えます。 PE上の1つ以上のVSIに、受信したS-PMSI A-Dルートによって運ばれる1つ以上のRTを含むインポートRTがある場合、そのようなVSIごとに、PEは以下を実行します。
Procedures for receiving an S-PMSI A-D route by a PE (both within and outside of the AS of the PE that originates the route) are the same as specified in the "Inter-AS A-D Route Received via IBGP" section, except that (a) instead of Inter-AS A-D routes the procedures apply to S-PMSI A-D routes, (b) the rules for determining whether the received S-PMSI A-D route is the best route to the destination carried in the NLRI of the route are the same as BGP path selection rules and may be modified by policy, and (c) a PE performs procedures specified in that section only if in addition to the criteria specified in that section the following is true:
PEがS-PMSI ADルートを受信する手順（ルートを発信するPEのASの内部と外部の両方）は、「IBGPを介して受信されたInter-AS ADルートの受信」セクションで指定されているものと同じですが、（ a）Inter-AS ADルートの代わりに、手順はS-PMSI ADルートに適用されます。（b）受信したS-PMSI ADルートがルートのNLRIで運ばれる宛先への最良のルートであるかどうかを決定するためのルールは、 BGPパス選択ルールと同じで、ポリシーによって変更できます。（c）PEは、そのセクションで指定された基準に加えて、次の条件が満たされている場合にのみ、そのセクションで指定された手順を実行します。
+ If, as a result of multicast state snooping on the PE-CE interfaces, the PE has snooped state for at least one multicast join that matches the multicast source and group advertised in the S-PMSI A-D route. Further, the oifs (outgoing interfaces) for this state contain one or more interfaces to the locally attached CEs. When the multicast signaling protocol among the CEs is IGMP, then snooping and associated procedures are defined in [RFC4541]. The snooped state is determined using these procedures. When the multicast signaling protocol among the CEs is PIM, the procedures in [RFC4541] are not sufficient to determine the snooped state. The additional details required to determine the snooped state when CE-CE protocol is PIM are for further study. When such procedures are defined, it is expected that the procedures in this section will apply to the snooped state created as a result of PIM as PE-CE protocol.
+ PE-CEインターフェイスでのマルチキャストステートスヌーピングの結果として、PEが、S-PMSI A-Dルートでアドバタイズされたマルチキャストソースおよびグループと一致する少なくとも1つのマルチキャストジョインの状態をスヌーピングした場合。さらに、この状態のoif（発信インターフェース）には、ローカルに接続されたCEへの1つ以上のインターフェースが含まれています。 CE間のマルチキャストシグナリングプロトコルがIGMPの場合、スヌーピングおよび関連する手順は[RFC4541]で定義されています。スヌープ状態は、これらの手順を使用して判別されます。 CE間のマルチキャストシグナリングプロトコルがPIMの場合、[RFC4541]の手順では、スヌーピング状態を判別するのに十分ではありません。 CE-CEプロトコルがPIMである場合にスヌープ状態を判別するために必要な追加の詳細は、今後の検討課題です。そのような手順が定義されている場合、このセクションの手順は、PE-CEプロトコルとしてのPIMの結果として作成されたスヌープ状態に適用されることが期待されます。
The snooped state is said to "match" the S-PMSI A-D route if any of the following is true:
スヌープ状態は、次のいずれかに該当する場合、S-PMSI A-Dルートに「一致」すると言われます。
+ The S-PMSI A-D route carries (C-S, C-G) and the snooped state is for (C-S, C-G) or for (C-*, C-G), OR
+ S-PMSI A-Dルートは（C-S、C-G）を伝送し、スヌープ状態は（C-S、C-G）または（C- *、C-G）の場合、または
+ The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped state is for (C-*, C-G) OR (b) the snooped state is for at least one multicast join with the multicast group address equal to C-G and there doesn't exist another S-PMSI A-D route that carries (C-S, C-G) where C-S is the source address of the snooped state.
+ S-PMSI ADルートは（C- *、CG）を伝送し、（a）スヌープ状態は（C- *、CG）であるか、または（b）スヌープ状態は、マルチキャストグループアドレスが等しい少なくとも1つのマルチキャスト参加であるCGに送信され、（CS、CG）を伝送する別のS-PMSI ADルートが存在しない場合、CSはスヌーピング状態のソースアドレスです。
+ The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped state is for at least one multicast join with the multicast source address equal to C-S, and (b) there doesn't exist another S-PMSI A-D route that carries (C-S, C-G) where C-G is the group address of the snooped state.
+ S-PMSI ADルートは（CS、C- *）を伝送し、（a）スヌーピング状態は、CSに等しいマルチキャスト送信元アドレスを持つ少なくとも1つのマルチキャスト参加であり、（b）別のS-PMSIが存在しない（CS、CG）を運ぶADルート。CGはスヌーピングされた状態のグループアドレスです。
+ The S-PMSI A-D route carries (C-*, C-*) and there is no other S-PMSI A-D route that matches the snooped state as per the above conditions.
+ S-PMSI A-Dルートは（C-*、C- *）を伝送し、上記の条件に従ってスヌーピング状態に一致する他のS-PMSI A-Dルートはありません。
Note if the above conditions are true, and if the received S-PMSI A-D route has a PMSI Tunnel attribute with the Leaf Information Required flag set to 1, then the PE originates a leaf A-D route, constructed as follows:
上記の条件に該当し、受信したS-PMSI A-Dルートに、Leaf Information Requiredフラグが1に設定されたPMSI Tunnel属性がある場合、PEは次のように構築されたリーフA-Dルートを発信します。
+ The route carries a single MCAST-VPLS NLRI with the Route Key field set to the MCAST-VPLS NLRI of the received S-PMSI A-D route.
+ ルートは、ルートキーフィールドが受信したS-PMSI A-DルートのMCAST-VPLS NLRIに設定された単一のMCAST-VPLS NLRIを伝送します。
+ The Originating Router's IP Address set to the IP address of the PE (this MUST be a routable IP address).
+ PEのIPアドレスに設定された発信元ルーターのIPアドレス（これはルーティング可能なIPアドレスでなければなりません）。
+ The PE constructs an IP-address-specific RT by placing the IP address carried in the Next Hop field of the received S-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0 and setting the Extended Communities attribute of the leaf A-D route to that Community.
+ PEは、受信したS-PMSI ADルートのNext Hopフィールドに含まれるIPアドレスをコミュニティのGlobal Administratorフィールドに配置し、このコミュニティのLocal Administratorフィールドを0に設定して、IPアドレス固有のRTを構築します。リーフADルートの拡張コミュニティ属性をそのコミュニティに設定します。
+ The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 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アドレスに設定されなければなりません（MUST）。
+ To constrain the distribution scope of this route, the route MUST carry the NO_EXPORT Community [RFC1997], except for the inter-AS scenario with option (c).
+ このルートの配信範囲を制限するには、オプション（c）を含むAS間シナリオを除いて、ルートはNO_EXPORTコミュニティ[RFC1997]を運ぶ必要があります。
Once the leaf A-D route is constructed, the PE advertises this route into IBGP.
リーフA-Dルートが構築されると、PEはこのルートをIBGPにアドバタイズします。
In addition to the procedures specified in the "Inter-AS A-D Route Received via IBGP" section, the PE MUST set up its forwarding path to receive traffic, for each multicast stream in the matching snooped state, from the tunnel advertised by the S-PMSI A-D route (the PE MUST switch to the Selective tree).
「IBGP経由で受信されたAS間ADルート」セクションで指定された手順に加えて、PEは、S-によってアドバタイズされたトンネルから、一致するスヌーピング状態のマルチキャストストリームごとにトラフィックを受信するための転送パスを設定する必要があります。 PMSI ADルート（PEは選択ツリーに切り替える必要があります）。
When a new snooped state is created by a PE, then the PE MUST first determine if there is an S-PMSI A-D route that matches the snooped state as per the conditions described above. If such an S-PMSI A-D route is found, then the PE MUST follow the procedures described in this section, for that particular S-PMSI A-D route. If later on the snooped state ages out and is deleted from the PE, the PE SHOULD withdraw the leaf A-D route that it had originated in response to the S-PMSI A-D route.
PEによって新しいスヌーピング状態が作成されると、PEは最初に、上記の条件に従ってスヌーピング状態に一致するS-PMSI A-Dルートがあるかどうかを判断する必要があります。そのようなS-PMSI A-Dルートが見つかった場合、PEはその特定のS-PMSI A-Dルートについて、このセクションで説明されている手順に従う必要があります。後でスヌーピングされた状態が期限切れになり、PEから削除された場合、PEはS-PMSI A-Dルートへの応答として発信したリーフA-Dルートを撤回する必要があります（SHOULD）。
Inter-AS Selective trees support all three options of inter-AS VPLS service, option (a), (b), and (c), that are supported by Inter-AS Inclusive trees. They are constructed in a manner that is very similar to Inter-AS Inclusive trees.
AS間選択ツリーは、AS間VPLSサービスの3つのオプション、オプション（a）、（b）、および（c）をすべてサポートします。これらは、AS間ツリーでサポートされています。それらは、Inter-ASインクルーシブツリーと非常によく似た方法で構築されます。
For option (a) and option (b), support Inter-AS Selective trees are constructed without requiring a single P-multicast tree to span multiple ASes. This allows individual ASes to potentially use different P-tunneling technologies. There are two variants of this. One that requires MAC and IP multicast lookup on the ASBRs and another that does not require MAC/IP multicast lookup on the ASBRs and instead builds segmented Inter-AS Selective trees.
オプション（a）およびオプション（b）の場合、複数のASにまたがる単一のPマルチキャストツリーを必要とせずに、AS間選択ツリーがサポートされます。これにより、個々のASが異なるPトンネリングテクノロジーを使用する可能性があります。これには2つのバリエーションがあります。 ASBRでMACおよびIPマルチキャストルックアップを必要とするものと、ASBRでMAC / IPマルチキャストルックアップを必要とせず、セグメント化されたInter-AS選択ツリーを構築するもの。
Segmented Inter-AS Selective trees can also be used with option (c), unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D routes are not exchanged via ASBRs).
セグメント化されたInter-AS選択的ツリーは、セグメント化されたInter-AS包括的ツリーとは異なり、オプション（c）で使用することもできます。これは、AS-BRを介してS-PMSI A-Dルートを交換できるためです（BGP VPLS A-DルートはASBRを介して交換されません）。
In the case of Option (c), an Inter-AS Selective tree may also be a non-segmented P-multicast tree that spans multiple ASes.
オプション（c）の場合、AS間選択ツリーは、複数のASにまたがるセグメント化されていないPマルチキャストツリーでもかまいません。
The requirements on ASBRs, when VSIs are present on the ABSRs, include the requirements presented in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section. The source ASBR (that receives traffic from another AS) may independently decide whether or not it wishes to use Selective trees. If it uses Selective trees, the source ASBR MUST perform a MAC lookup to determine the Selective tree to forward the VPLS packet on.
ASBRの要件には、ABSIにVSIが存在する場合、「AS間のPマルチキャストツリーA-D /バインディング」セクションに示されている要件が含まれます。 （別のASからトラフィックを受信する）ソースASBRは、選択的ツリーを使用するかどうかを個別に決定できます。選択ツリーを使用する場合、ソースASBRはMACルックアップを実行して、VPLSパケットを転送する選択ツリーを決定する必要があります。
The mechanisms for propagating S-PMSI A-D routes are the same as the intra-AS case described in the "MCAST-VPLS NLRI" section. The BGP Selective tree A-D routes generated by PEs in an AS MUST NOT be propagated outside the AS.
S-PMSI A-Dルートを伝播するメカニズムは、「MCAST-VPLS NLRI」で説明したAS内の場合と同じです。 AS内のPEによって生成されたBGP選択ツリーA-Dルートは、AS外に伝播してはいけません。
Inter-AS Segmented Selective trees MUST be implemented when option (b) is used to provide the inter-AS VPLS service. They MAY be used when option (c) is implemented to provide the inter-AS VPLS service.
AS間VPLSサービスを提供するためにオプション（b）が使用される場合、AS間セグメント化選択ツリーを実装する必要があります。それらは、AS間VPLSサービスを提供するためにオプション（c）が実装されている場合に使用できます。
A Segmented inter-AS Selective Tunnel is constructed similar to an inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is constructed as a concatenation of tunnel segments. There are two types of tunnel segments: an intra-AS tunnel segment (a segment that spans ASBRs within the same AS) and inter-AS tunnel segment (a segment that spans adjacent ASBRs in adjacent ASes). ASes that are spanned by a tunnel are not required to use the same tunneling mechanism to construct the tunnel -- each AS may pick up a tunneling mechanism to construct the intra-AS tunnel segment of the tunnel, in its AS.
セグメント化された相互AS選択的トンネルは、AS間セグメント化包括的トンネルと同様に構築されます。つまり、このようなトンネルは、トンネルセグメントの連結として構築されます。トンネルセグメントには、AS内トンネルセグメント（同じAS内のASBRにまたがるセグメント）とAS間トンネルセグメント（隣接AS内の隣接ASBRにまたがるセグメント）の2種類があります。トンネルがまたがるASは、同じトンネリングメカニズムを使用してトンネルを構築する必要はありません。各ASは、トンネリングメカニズムを取得して、AS内にトンネルのAS内トンネルセグメントを構築できます。
The PE that decides to set up a Selective tree advertises the Selective tree to multicast stream binding using an S-PMSI A-D route, as per procedures in the "Advertising (C-S, C-G) Binding to a Selective Tree" section, to the routers in its own AS.
選択ツリーのセットアップを決定したPEは、「選択ツリーへのアドバタイズ（CS、CG）バインディング」の手順に従って、S-PMSI ADルートを使用して、選択ツリーをマルチキャストストリームバインディングにアドバタイズします。独自のAS。
An S-PMSI A-D route advertised outside the AS, to which the originating PE belongs, will be referred to as an Inter-AS S-PMSI tree A-D route (although this route is originated by a PE as an intra-AS S-PMSI A-D route, it is referred to as an Inter-AS route outside the AS).
元のPEが属するASの外部でアドバタイズされるS-PMSI ADルートは、Inter-AS S-PMSIツリーADルートと呼ばれます（このルートは、AS内のS-PMSIとしてPEによって発信されますが） ADルート、これはAS外のInter-ASルートと呼ばれます）。
Procedures for handling an S-PMSI A-D route by ASBRs (both within and outside of the AS of the PE that originates the route) are the same as specified in the "Propagating BGP VPLS A-D Routes to Other ASes" section, except that instead of Inter-AS A-D routes and their NLRI, these procedures apply to S-PMSI A-D routes and their NLRI.
ASBRによってS-PMSI ADルートを処理する手順（ルートを発信するPEのASの内部と外部の両方）は、「他のASへのBGP VPLS ADルートの伝播」で指定したものと同じですが、 AS間ADルートとそのNLRI、これらの手順はS-PMSI ADルートとそのNLRIに適用されます。
In addition to these procedures, an ASBR advertises a leaf A-D route in response to an S-PMSI A-D route only if:
これらの手順に加えて、ASBRは、次の場合にのみ、S-PMSI A-Dルートに応答してリーフA-Dルートをアドバタイズします。
+ The S-PMSI A-D route was received via EBGP from another ASBR and the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS A-D route as described in the next section. OR
+ S-PMSI A-Dルートは別のASBRからEBGP経由で受信され、ASBRは次のセクションで説明するようにS-PMSI A-DルートをInter-AS BGP VPLS A-Dルートにマージします。または
+ The ASBR receives a leaf A-D route from a downstream PE or ASBR in response to the S-PMSI A-D route, received from an upstream PE or ASBR, that the ASBR propagated inter-AS to downstream ASBRs and PEs.
+ ASBRは、上流のPEまたはASBRから受信したS-PMSI A-Dルートに応答して、下流のPEまたはASBRからリーフA-Dルートを受信します。
+ The ASBR has snooped state from local CEs that matches the NLRI carried in the S-PMSI A-D route as per the following rules:
+ ASBRは、次のルールに従って、S-PMSI A-Dルートで伝送されるNLRIと一致するローカルCEから状態をスヌーピングしました。
i) The NLRI encodes (C-S, C-G), which is the same as the snooped (C-S, C-G)
i) NLRIエンコード（C-S、C-G）、これはスヌーピング（C-S、C-G）と同じ
ii) The NLRI encodes (*, C-G), there is snooped state for at least one (C-S, C-G), and there is no other matching S-PMSI A-D route for (C-S, C-G) OR there is snooped state for (*, C-G)
ii）NLRIエンコード（*、CG）、少なくとも1つ（CS、CG）のスヌープ状態があり、（CS、CG）に一致する他のS-PMSI ADルートがない、または（* 、CG）
iii) The NLRI encodes (*, *), there is snooped state for at least one (C-S, C-G) or (*, C-G), and there is no other matching S-PMSI A-D route for that (C-S, C-G) or (*, C-G), respectively.
iii）NLRIが（*、*）をエンコードし、少なくとも1つ（CS、CG）または（*、CG）のスヌープ状態があり、その（CS、CG）または他の一致するS-PMSI ADルートがない（*、CG）、それぞれ。
The C-multicast data traffic is sent on the Selective tree by the originating PE. When it reaches an ASBR that is on the inter-AS segmented tree, it is delivered to local receivers, if any. It is then forwarded on any inter-AS or intra-AS segments that exist on the Inter-AS Selective segmented tree. If the Inter-AS Selective segmented tree is merged onto an Inclusive tree, as described in the next section, the data traffic is forwarded onto the Inclusive tree.
Cマルチキャストデータトラフィックは、元のPEによって選択ツリーで送信されます。 AS間セグメント化ツリー上にあるASBRに到達すると、ローカル受信者に配信されます（ある場合）。次に、AS間選択的セグメントツリーに存在するAS間またはAS内セグメントで転送されます。次のセクションで説明するように、Inter-AS選択的セグメントツリーが包含ツリーにマージされると、データトラフィックは包含ツリーに転送されます。
Consider the situation where:
以下の状況を考えてみましょう。
+ An ASBR is receiving (or expecting to receive) inter-AS (C-S, C-G) data from upstream via a Selective tree.
+ ASBRは、選択ツリーを介してアップストリームからAS間（C-S、C-G）のデータを受信しています（または受信することを期待しています）。
+ The ASBR is sending (or expecting to send) the inter-AS (C-S, C-G) data downstream via an Inclusive tree.
+ ASBRが、AS間（C-S、C-G）のデータを包含ツリーを介してダウンストリームに送信（または送信予定）しています。
This situation may arise if the upstream providers have a policy of using Selective trees but the downstream providers have a policy of using Inclusive trees. To support this situation, an ASBR MAY, under certain conditions, merge one or more upstream Selective trees into a downstream Inclusive tree. Note that this can be the case only for option (b) and not for option (c) as, for option (c), the ASBRs do not have Inclusive tree state.
この状況は、上流プロバイダーが選択ツリーを使用するポリシーを持っているが、下流プロバイダーが包括的ツリーを使用するポリシーを持っている場合に発生する可能性があります。この状況をサポートするために、ASBRは、特定の条件下で、1つ以上のアップストリーム選択ツリーをダウンストリーム包含ツリーにマージできます（MAY）。 ASBRには包含ツリー状態がないため、これはオプション（b）の場合にのみ該当し、オプション（c）の場合には該当しないことに注意してください。
A Selective tree (corresponding to a particular S-PMSI A-D route) MAY be merged by a particular ASBR into an Inclusive tree (corresponding to a particular Inter-AS BGP VPLS A-D route) if and only if the following conditions all hold:
（特定のS-PMSI A-Dルートに対応する）選択的ツリーは、次の条件がすべて成立する場合に限り、特定のASBRによって（特定のInter-AS BGP VPLS A-Dルートに対応する）包含ツリーにマージされる場合があります。
+ The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route originate in the same AS. The Inter-AS BGP VPLS A-D route carries the originating AS in the AS_PATH attribute of the route. The S-PMSI A-D route carries the originating AS in the AS_PATH attribute of the route.
+ S-PMSI A-DルートとInter-AS BGP VPLS A-Dルートは、同じASから発信されます。 Inter-AS BGP VPLS A-Dルートは、ルートのAS_PATH属性で元のASを伝送します。 S-PMSI A-Dルートは、ルートのAS_PATH属性で元のASを伝送します。
+ The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have exactly the same set of RTs.
+ S-PMSI A-DルートとInter-AS BGP VPLS A-Dルートは、まったく同じRTセットを持っています。
An ASBR performs merging by stitching the tail end of the P-tunnel, as specified in the PMSI Tunnel attribute of the S-PMSI A-D route received by the ASBR, to the head of the P-tunnel, as specified in the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route re-advertised by the ASBR.
ASBRは、ASBRによって受信されたS-PMSI ADルートのPMSIトンネル属性で指定されたPトンネルのテールエンドを、PMSIトンネル属性で指定されたPトンネルのヘッドにステッチすることによって、マージを実行します。 ASBRによって再アドバタイズされたInter-AS BGP VPLS ADルートの。
An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D route MUST NOT re-advertise the S-PMSI A-D route.
S-PMSI A-DルートをInter-AS BGP VPLS A-DルートにマージするASBRは、S-PMSI A-Dルートを再アドバタイズしてはなりません。
Inter-AS Non-segmented Selective trees MAY be used in the case of option (c).
Inter-AS非セグメント化選択ツリーは、オプション（c）の場合に使用できます（MAY）。
In this method, there is a multi-hop EBGP peering between the PEs (or a Route Reflector) in one AS and the PEs (or Route Reflector) in another AS. The PEs exchange BGP Selective tree A-D routes, along with PMSI Tunnel attribute, as in the intra-AS case described in the "Option (c): Non-segmented Tunnels" section.
この方法では、あるASのPE（またはルートリフレクター）と別のASのPE（またはルートリフレクター）の間にマルチホップEBGPピアリングがあります。 「オプション（c）：セグメント化されていないトンネル」で説明したAS内の場合と同様に、PEはBGP選択ツリーA-DルートとPMSIトンネル属性を交換します。
The PEs in different ASes use a non-segmented Selective inter-AS P2MP tunnel for VPLS multicast.
異なるASのPEは、VPLSマルチキャストにセグメント化されていない選択的Inter-AS P2MPトンネルを使用します。
This method requires no VPLS information (in either the control or the data plane) on the ASBRs. The ASBRs only need to participate in the non-segmented P2MP tunnel setup in the control plane and do MPLS label forwarding in the data plane.
この方法では、ASBRに（コントロールプレーンまたはデータプレーンのいずれかに）VPLS情報は必要ありません。 ASBRは、コントロールプレーンのセグメント化されていないP2MPトンネルセットアップに参加し、データプレーンでMPLSラベル転送を行うだけです。
The data forwarding in this model is the same as in the intra-AS case described in the "Establishing P-Multicast Trees" section.
このモデルのデータ転送は、「Pマルチキャストツリーの確立」で説明したAS内の場合と同じです。
This section describes the encoding of the BGP extensions required by this document.
このセクションでは、このドキュメントで必要なBGP拡張のエンコードについて説明します。
Inclusive P-multicast tree and Selective P-multicast tree advertisements carry the P-multicast tree identifier. For the purpose of carrying this identifier, this document reuses the BGP attribute, called "PMSI_TUNNEL" that is defined in [RFC6514].
包括的Pマルチキャストツリーおよび選択的Pマルチキャストツリーアドバタイズには、Pマルチキャストツリー識別子が含まれます。このドキュメントはこの識別子を伝えるために、[RFC6514]で定義されている「PMSI_TUNNEL」と呼ばれるBGP属性を再利用します。
This document supports only the following Tunnel Types when the PMSI Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes:
PMSIトンネル属性がVPLS A-DまたはVPLS S-PMSI A-Dルートで伝送される場合、このドキュメントは次のトンネルタイプのみをサポートします。
+ 0 - No tunnel information present
+ 1 - RSVP-TE P2MP LSP
+ 2 - LDP P2MP LSP
+ 6 - Ingress Replication
This document defines a new BGP NLRI, called the "MCAST-VPLS NLRI".
このドキュメントでは、「MCAST-VPLS NLRI」と呼ばれる新しいBGP NLRIを定義します。
Following is the format of the MCAST-VPLS NLRI:
MCAST-VPLS NLRIの形式は次のとおりです。
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
The Route Type field defines encoding of the Route Type specific field of MCAST-VPLS NLRI.
ルートタイプフィールドは、MCAST-VPLS NLRIのルートタイプ固有フィールドのエンコーディングを定義します。
The Length field indicates the length in octets of the Route Type specific field of MCAST-VPLS NLRI.
長さフィールドは、MCAST-VPLS NLRIのルートタイプ固有フィールドのオクテットの長さを示します。
This document defines the following route types for A-D routes:
このドキュメントでは、A-Dルートの次のルートタイプを定義しています。
+ 3 - Selective Tree A-D route; + 4 - Leaf A-D route.
+ 3-選択ツリーA-Dルート。 + 4-リーフA-Dルート。
The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of 25 (L2VPN AFI), and a Subsequent Address Family Identifier (SAFI) of MCAST-VPLS. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPLS NLRI (encoded as specified above).
MCAST-VPLS NLRIは、アドレスファミリ識別子（AFI）が25（L2VPN AFI）のBGPマルチプロトコル拡張[RFC4760]とMCAST-VPLSの後続アドレスファミリ識別子（SAFI）を使用してBGPで伝送されます。 MP_REACH_NLRI / MP_UNREACH_NLRI属性のNLRIフィールドには、MCAST-VPLS NLRI（上記のようにエンコード）が含まれています。
In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP) with an AFI of 25 and a SAFI of MCAST-VPLS.
2つのBGPスピーカーがラベル付きMCAST-VPLS NLRIを交換するには、BGP機能アドバタイズメントを使用して、両方がそのようなNLRIを適切に処理できることを確認する必要があります。これは、[RFC4760]で指定されているように、25のAFIとMCAST-VPLSのSAFIを備えた機能コード1（マルチプロトコルBGP）を使用して行われます。
The following describes the format of the Route Type specific field of MCAST-VPLS NLRI for various route types defined in this document.
このドキュメントで定義されているさまざまなルートタイプのMCAST-VPLS NLRIのルートタイプ固有のフィールドの形式を次に示します。
The Route Type specific field of MCAST-VPLS NLRI of an S-PMSI A-D route consists of the following:
S-PMSI A-DルートのMCAST-VPLS NLRIのルートタイプ固有フィールドは、次のもので構成されます。
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
The RD is encoded as described in [RFC4364].
RDは、[RFC4364]で説明されているようにエンコードされます。
The Multicast Source field contains the C-S address, i.e., the address of the multicast source. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128. The value of the Multicast Source Length field may be set to 0 to indicate a wildcard.
Multicast Sourceフィールドには、C-Sアドレス、つまりマルチキャストソースのアドレスが含まれます。マルチキャストソースフィールドにIPv4アドレスが含まれている場合、マルチキャストソース長フィールドの値は32です。マルチキャストソースフィールドにIPv6アドレスが含まれている場合、マルチキャストソース長フィールドの値は128です。マルチキャストソースの値ワイルドカードを示すために、長さフィールドを0に設定できます。
The Multicast Group field contains the C-G address, i.e., the address of the multicast group. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128. The Multicast Group Length field may be set to 0 to indicate a wildcard.
Multicast Groupフィールドには、C-Gアドレス、つまりマルチキャストグループのアドレスが含まれます。マルチキャストグループフィールドにIPv4アドレスが含まれている場合、マルチキャストグループ長フィールドの値は32です。マルチキャストグループフィールドにIPv6アドレスが含まれている場合、マルチキャストグループ長フィールドの値は128です。マルチキャストグループ長フィールドは、ワイルドカードを示すには0に設定します。
Whether the Originating Router's IP Address field carries an IPv4 or IPv6 address is determined by the value of the Length field of the MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4 address and the Multicast Group field contains an IPv4 address, then the value of the Length field is 22 bytes if the Originating Router's IP Address carries an IPv4 address and 34 bytes if it is an IPv6 address. If the Multicast Source and Multicast Group fields contain IPv6 addresses, then the value of the Length field is 46 bytes if the Originating Router's IP Address carries an IPv4 address and 58 bytes if it is an IPv6 address. The following table summarizes the above.
発信元ルーターのIPアドレスフィールドにIPv4またはIPv6アドレスが含まれるかどうかは、MCAST-VPLS NLRIの長さフィールドの値によって決まります。マルチキャストソースフィールドにIPv4アドレスが含まれ、マルチキャストグループフィールドにIPv4アドレスが含まれている場合、長さフィールドの値は、発信元ルーターのIPアドレスがIPv4アドレスを持っている場合は22バイト、IPv6アドレスの場合は34バイトです。 Multicast SourceおよびMulticast GroupフィールドにIPv6アドレスが含まれている場合、Lengthフィールドの値は、発信元ルーターのIPアドレスがIPv4アドレスを伝送する場合は46バイト、IPv6アドレスを伝送する場合は58バイトです。次の表は、上記をまとめたものです。
Multicast Multicast Originating Router's Length Source Group IP Address
マルチキャストマルチキャスト発信ルーターの長さソースグループIPアドレス
IPv4 IPv4 IPv4 22 IPv4 IPv4 IPv6 34 IPv6 IPv6 IPv4 46 IPv6 IPv6 IPv6 58
IPv4 IPv4 IPv4 22 IPv4 IPv4 IPv6 34 IPv6 IPv6 IPv4 46 IPv6 IPv6 IPv6 58
Usage of Selective Tree A-D routes is described in the "Optimizing Multicast Distribution via Selective Trees" section.
選択的ツリーA-Dルートの使用については、「選択的ツリーによるマルチキャスト配信の最適化」で説明しています。
The Route Type specific field of MCAST-VPLS NLRI of a leaf A-D route consists of the following:
リーフA-DルートのMCAST-VPLS NLRIのルートタイプ固有フィールドは、次のもので構成されます。
+-----------------------------------+
| Route Key (variable) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
Whether the Originating Router's IP Address field carries an IPv4 or IPv6 address is determined by the Length field of the MCAST-VPLS NLRI and the length of the Route Key field. From these two length fields, one can compute the length of the Originating Router's IP Address. If this computed length is 4, then the address is an IPv4 address; if its 16, then the address is an IPv6 address.
発信元ルーターのIPアドレスフィールドにIPv4またはIPv6アドレスが含まれるかどうかは、MCAST-VPLS NLRIの長さフィールドとルートキーフィールドの長さによって決まります。これら2つの長さフィールドから、発信元ルーターのIPアドレスの長さを計算できます。この計算された長さが4の場合、アドレスはIPv4アドレスです。その16の場合、アドレスはIPv6アドレスです。
Usage of leaf A-D routes is described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution via Selective Trees" sections.
リーフA-Dルートの使用法については、「AS間のPマルチキャストツリーA-D /バインディング」および「選択的ツリーによるマルチキャスト配信の最適化」セクションで説明しています。
This document does not specify the mandatory implementation of any particular set of rules for determining whether or not the Inclusive or Selective trees of two particular VPLS instances are to be instantiated by the same Aggregate Inclusive/Selective tree. This determination can be made by implementation-specific heuristics, by configuration, or even perhaps by the use of offline tools.
このドキュメントでは、2つの特定のVPLSインスタンスの包括的ツリーまたは選択的ツリーが同じ集約包括的/選択的ツリーによってインスタンス化されるかどうかを決定するための特定の一連のルールの必須の実装を指定していません。この決定は、実装固有のヒューリスティック、構成、またはオフラインツールの使用によって行うことができます。
This section discusses potential methodologies with respect to aggregation.
このセクションでは、集約に関して考えられる方法論について説明します。
In general, the heuristic used to decide which VPLS instances or <C-S, C-G> entries to aggregate is implementation dependent. It is also conceivable that offline tools can be used for this purpose. This section discusses some trade-offs with respect to aggregation.
一般に、集約するVPLSインスタンスまたは<C-S、C-G>エントリを決定するために使用されるヒューリスティックは、実装に依存します。この目的のためにオフラインツールを使用できることも考えられます。このセクションでは、集計に関するいくつかのトレードオフについて説明します。
The "congruency" of aggregation is defined by the amount of overlap in the leaves of the client trees that are aggregated on an SP tree. For Aggregate Inclusive trees, the congruency depends on the overlap in the membership of the VPLS instances that are aggregated on the Aggregate Inclusive tree. If there is complete overlap, aggregation is perfectly congruent. As the overlap between the VPLS instances that are aggregated reduces, the congruency reduces.
集約の「合同性」は、SPツリーに集約されるクライアントツリーのリーフのオーバーラップの量によって定義されます。 Aggregate Inclusiveツリーの場合、合同性は、Aggregate Inclusiveツリーに集約されるVPLSインスタンスのメンバーシップの重複に依存します。完全に重複している場合、集約は完全に合同です。集約されたVPLSインスタンス間のオーバーラップが減少すると、合同性が低下します。
From the above definition of "congruency", it follows that in order for a given PE to determine the congruency of the client trees that this PE could aggregate, the PE has to know the leaves of these client trees. This is irrespective of whether the aggregated SP tree is established using mLDP or RSVP-TE.
上記の「合同性」の定義から、特定のPEがこのPEが集約できるクライアントツリーの合同性を決定するためには、PEがこれらのクライアントツリーのリーフを知る必要があるということになります。これは、集約されたSPツリーがmLDPまたはRSVP-TEのどちらを使用して確立されているかには関係ありません。
If aggregation is done such that it is not perfectly congruent, a PE may receive traffic for VPLS instances to which it doesn't belong. As the amount of multicast traffic in these unwanted VPLS instances increases, aggregation becomes less optimal with respect to delivered traffic. Hence, there is a trade-off between reducing multicast state in the core and delivering unwanted traffic.
完全に一致しないように集約が行われると、PEは、属していないVPLSインスタンスのトラフィックを受信する可能性があります。これらの不要なVPLSインスタンスのマルチキャストトラフィックの量が増えると、配信されるトラフィックに関して集約が最適でなくなります。したがって、コアのマルチキャスト状態を減らすことと、不要なトラフィックを配信することの間にはトレードオフがあります。
An implementation should provide knobs to control aggregation based on the congruency of the tree to be aggregated. This will allow an SP to deploy aggregation depending on the VPLS membership and traffic profiles in its network. If different PEs are setting up Aggregate Inclusive trees, this will also allow an SP to engineer the maximum amount of unwanted VPLS instances for which a particular PE may receive traffic.
実装は、集約されるツリーの合同性に基づいて集約を制御するためのノブを提供する必要があります。これにより、SPはネットワーク内のVPLSメンバーシップとトラフィックプロファイルに応じて集約を展開できます。異なるPEが集合インクルーシブツリーをセットアップしている場合、これによりSPは、特定のPEがトラフィックを受信する可能性のある不要なVPLSインスタンスの最大量を設計することもできます。
The state/bandwidth optimality trade-off can be further improved by having a versatile many-to-many association between client trees and provider trees. Thus, a VPLS instance can be mapped to multiple Aggregate trees. The mechanisms for achieving this are for further study. Also, it may be possible to use both ingress replication and an Aggregate tree for a particular VPLS. Mechanisms for achieving this are also for further study.
状態/帯域幅の最適性のトレードオフは、クライアントツリーとプロバイダーツリーの間に多対多の多目的な関連付けを行うことでさらに改善できます。したがって、VPLSインスタンスを複数の集約ツリーにマップできます。これを達成するためのメカニズムは、今後の検討課題です。また、特定のVPLSに入力レプリケーションと集約ツリーの両方を使用できる場合もあります。これを達成するためのメカニズムも、今後の検討課題です。
The following diagram shows the progression of the VPLS multicast packet as it enters and leaves the SP network when MPLS trees are being used for multiple VPLS instances. RSVP-TE P2MP LSPs are examples of such trees.
次の図は、MPLSツリーが複数のVPLSインスタンスに使用されている場合に、SPネットワークに出入りするVPLSマルチキャストパケットの進行を示しています。 RSVP-TE P2MP LSPは、このようなツリーの例です。
Packets received Packets in transit Packets forwarded at ingress PE in the service by egress PEs provider network
受信したパケット送信中のパケットサービスの入力PEで出力PEプロバイダーネットワークによって転送されたパケット
+---------------+
|MPLS Tree Label|
+---------------+
| VPLS Label |
++=============++ ++=============++ ++=============++
||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
When an ingress PE receives a packet, the ingress PE using the procedures defined in [RFC4761] and [RFC4762] determines the VPLS instance associated with the packet. If the packet is an IP multicast packet, and the ingress PE uses an Aggregate Selective tree for the (C-S, C-G) carried in the packet, then the ingress PE pushes the VPLS Label associated with the VPLS instance on the ingress PE and the MPLS Tree Label associated with the Aggregate Selective tree, and it sends the packet over the P2MP LSP associated with the Aggregate Selective tree. Otherwise, if the ingress PE does not use an Aggregate Selective tree for the (C-S, C-G), or the packet is either non-IP multicast or broadcast, the ingress PE pushes the VPLS label associated with the VPLS instance on the ingress PE and the MPLS Tree Label associated with the Aggregate Inclusive tree, and it sends the packet over the P2MP LSP associated with the Aggregate Inclusive tree.
入力PEがパケットを受信すると、[RFC4761]および[RFC4762]で定義された手順を使用する入力PEが、パケットに関連付けられているVPLSインスタンスを決定します。パケットがIPマルチキャストパケットであり、入力PEがパケットで運ばれる（CS、CG）の集約選択ツリーを使用している場合、入力PEは、入力PEおよびMPLS上のVPLSインスタンスに関連付けられたVPLSラベルをプッシュします。集約選択ツリーに関連付けられているツリーラベル。集約選択ツリーに関連付けられているP2MP LSPを介してパケットを送信します。それ以外の場合、入力PEが（CS、CG）の集約選択ツリーを使用しないか、パケットが非IPマルチキャストまたはブロードキャストのいずれかである場合、入力PEは入力PE上のVPLSインスタンスに関連付けられたVPLSラベルをプッシュし、 Aggregate Inclusive Treeに関連付けられたMPLSツリーラベル。AggregateInclusive Treeに関連付けられたP2MP LSPを介してパケットを送信します。
The egress PE does a lookup on the outer MPLS tree label, and determines the MPLS forwarding table in which to look up the inner MPLS label (VPLS label). This table is specific to the tree label space (as identified by the MPLS Tree Label). The inner label (VPLS label) is unique within the context of the root of the tree (as it is assigned by the root of the tree, without any coordination with any other nodes). Thus, it is not unique across multiple roots. So, to unambiguously identify a particular VPLS, one has to know the VPLS label, and the context within which that label is unique. The context is provided by the outer MPLS label (MPLS Tree Label) [RFC5331].
出力PEは、外部MPLSツリーラベルを検索し、内部MPLSラベル（VPLSラベル）を検索するMPLS転送テーブルを決定します。このテーブルは、（MPLSツリーラベルで識別される）ツリーラベルスペースに固有です。内部ラベル（VPLSラベル）は、ツリーのルートのコンテキスト内で一意です（他のノードとの調整なしに、ツリーのルートによって割り当てられるため）。したがって、複数のルート間で一意ではありません。したがって、特定のVPLSを明確に識別するには、VPLSラベルと、そのラベルが一意であるコンテキストを知る必要があります。コンテキストは、外部MPLSラベル（MPLSツリーラベル）[RFC5331]によって提供されます。
The outer MPLS label is popped. The lookup of the resulting MPLS label determines the VSI in which the egress PE needs to do the C-multicast data packet lookup. It then pops the inner MPLS label and sends the packet to the VSI for multicast data forwarding.
外側のMPLSラベルがポップされます。結果のMPLSラベルのルックアップは、出力PEがCマルチキャストデータパケットルックアップを実行する必要があるVSIを決定します。次に、内部MPLSラベルをポップし、マルチキャストデータ転送のためにパケットをVSIに送信します。
The following diagram shows the progression of the VPLS multicast packet as it enters and leaves the SP network when a given MPLS tree is being used for a single VPLS instance. RSVP-TE P2MP LSPs are examples of such trees.
次の図は、特定のMPLSツリーが単一のVPLSインスタンスに使用されている場合に、SPネットワークに出入りするVPLSマルチキャストパケットの進行を示しています。 RSVP-TE P2MP LSPは、このようなツリーの例です。
Packets received Packets in transit Packets forwarded at ingress PE in the service by egress PEs provider network
受信したパケット送信中のパケットサービスの入力PEで出力PEプロバイダーネットワークによって転送されたパケット
+---------------+
|MPLS Tree Label|
++=============++ ++=============++ ++=============++
||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
When an ingress PE receives a packet, the ingress PE using the procedures defined in [RFC4761] and [RFC4762] determines the VPLS instance associated with the packet. If the packet is an IP multicast packet, and the ingress PE uses a Selective tree for the (C-S, C-G) carried in the packet, then the ingress PE pushes the MPLS Tree Label associated with the Selective tree, and it sends the packet over the P2MP LSP associated with the Selective tree. Otherwise, if the ingress PE does not use a Selective tree for the (C-S, C-G), or the packet is either non-IP multicast or broadcast, the ingress PE pushes the MPLS Tree Label associated with the Inclusive tree, and it sends the packet over the P2MP LSP associated with the Inclusive tree.
入力PEがパケットを受信すると、[RFC4761]および[RFC4762]で定義された手順を使用する入力PEが、パケットに関連付けられているVPLSインスタンスを決定します。パケットがIPマルチキャストパケットであり、入力PEがパケットで運ばれる（CS、CG）の選択ツリーを使用する場合、入力PEは選択ツリーに関連付けられたMPLSツリーラベルをプッシュし、パケットを送信します。選択ツリーに関連付けられているP2MP LSP。それ以外の場合、入力PEが（CS、CG）の選択ツリーを使用しないか、パケットが非IPマルチキャストまたはブロードキャストのいずれかである場合、入力PEは包含ツリーに関連付けられたMPLSツリーラベルをプッシュし、包含ツリーに関連付けられたP2MP LSP上のパケット。
The egress PE does a lookup on the MPLS tree label and determines the VSI in which the receiver PE needs to do the C-multicast data packet lookup. It then pops the MPLS label and sends the packet to the VSI for multicast data forwarding.
出力PEはMPLSツリーラベルでルックアップを行い、レシーバーPEがCマルチキャストデータパケットルックアップを実行する必要があるVSIを決定します。次に、MPLSラベルをポップし、マルチキャストデータ転送のためにパケットをVSIに送信します。
If the destination MAC address of a VPLS packet received by an ingress PE from a VPLS site is a multicast address, a P-multicast tree SHOULD be used to transport the packet, if possible. If the packet is an IP multicast packet and a Selective tree exists for that multicast stream, the Selective tree MUST be used. Else, if a (C-*, C-*) Selective tree exists for the VPLS it SHOULD be used. Else, if an Inclusive tree exists for the VPLS, it SHOULD be used.
入力PEがVPLSサイトから受信したVPLSパケットの宛先MACアドレスがマルチキャストアドレスである場合、可能であれば、Pマルチキャストツリーを使用してパケットを転送する必要があります（SHOULD）。パケットがIPマルチキャストパケットであり、そのマルチキャストストリームに選択ツリーが存在する場合は、選択ツリーを使用する必要があります。それ以外の場合、VPLSに（C- *、C- *）選択ツリーが存在する場合は、それを使用する必要があります（SHOULD）。そうでない場合、VPLSに包含ツリーが存在する場合は、それを使用する必要があります（SHOULD）。
If the destination MAC address of a VPLS packet is a broadcast address, it is flooded. If a (C-*, C-*) Selective tree exists for the VPLS, the PE SHOULD flood over it. Else, if an Inclusive tree exists for the VPLS, the PE SHOULD flood over it. Else, the PE MUST flood the packet using the procedures in [RFC4761] or [RFC4762].
VPLSパケットの宛先MACアドレスがブロードキャストアドレスの場合、フラッディングされます。 （C-*、C- *）選択ツリーがVPLSに存在する場合、PEはその上にフラッディングする必要があります。そうでない場合、VPLSに包含ツリーが存在する場合、PEはその上にフラッディングする必要があります。そうでない場合、PEは、[RFC4761]または[RFC4762]の手順を使用してパケットをフラッディングする必要があります。
If the destination MAC address of a packet is a unicast address and it has not been learned, the packet MUST be sent to all PEs in the VPLS. Inclusive P-multicast trees or a Selective P-multicast tree bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC packets to all PEs. When this is the case, the receiving PEs MUST support the ability to perform MAC address learning for packets received on a multicast tree. In order to perform such learning, the receiver PE MUST be able to determine the sender PE when a VPLS packet is received on a P-multicast tree. This further implies that the MPLS P-multicast tree technology MUST allow the egress PE to determine the sender PE from the received MPLS packet.
パケットの宛先MACアドレスがユニキャストアドレスであり、学習されていない場合、パケットはVPLS内のすべてのPEに送信される必要があります。包括的Pマルチキャストツリーまたは（C- *、C- *）にバインドされた選択的Pマルチキャストツリーは、すべてのPEに未知のユニキャストMACパケットを送信するために使用する必要があります。この場合、受信PEは、マルチキャストツリーで受信されたパケットのMACアドレス学習を実行する機能をサポートする必要があります。そのような学習を実行するために、VPLSパケットがPマルチキャストツリーで受信されるとき、受信側PEは送信側PEを決定できなければなりません（MUST）。これはさらに、MPLS Pマルチキャストツリーテクノロジーが、出力PEが受信したMPLSパケットから送信側PEを決定できるようにする必要があることを意味します。
When a receiver PE receives a VPLS packet with a source MAC address, which has not yet been learned, on a P-multicast tree, the receiver PE determines the PW to the sender PE. The receiver PE then creates forwarding state in the VPLS instance with a destination MAC address being the same as the source MAC address being learned, and the PW being the PW to the sender PE.
受信側PEが、まだ学習されていない送信元MACアドレスを持つVPLSパケットをPマルチキャストツリーで受信すると、送信側PEへのPWを決定します。次に、受信側PEは、VPLSインスタンスで転送状態を作成します。宛先MACアドレスは学習中の送信元MACアドレスと同じであり、PWは送信側PEへのPWです。
It should be noted that when a sender PE that is sending packets destined to an unknown unicast MAC address over a P-multicast tree learns the PW to use for forwarding packets destined to this unicast MAC address, it might immediately switch to transport such packets over this particular PW. Since the packets were initially being forwarded using a P-multicast tree, this could lead to packet reordering. This constraint should be taken into consideration if unknown unicast frames are forwarded using a P-multicast tree, instead of multiple PWs based on [RFC4761] or [RFC4762].
Pマルチキャストツリーを介して不明なユニキャストMACアドレス宛のパケットを送信している送信側PEが、このユニキャストMACアドレス宛のパケットの転送に使用するPWを学習すると、すぐにそのようなパケットをトランスポートするように切り替わることに注意してください。この特定のPW。パケットは最初はPマルチキャストツリーを使用して転送されていたため、パケットの並べ替えが発生する可能性があります。 [RFC4761]または[RFC4762]に基づく複数のPWではなく、Pマルチキャストツリーを使用して未知のユニキャストフレームが転送される場合は、この制約を考慮する必要があります。
An implementation SHOULD support the ability to transport unknown unicast traffic over Inclusive P-multicast trees. Furthermore, an implementation MUST support the ability to perform MAC address learning for packets received on a P-multicast tree.
実装は、包含Pマルチキャストツリーを介して未知のユニキャストトラフィックを転送する機能をサポートする必要があります（SHOULD）。さらに、実装はPマルチキャストツリーで受信したパケットのMACアドレス学習を実行する機能をサポートする必要があります。
Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. This section describes additional considerations.
[RFC4761]および[RFC4762]で説明されているセキュリティの考慮事項がこのドキュメントに適用されます。このセクションでは、追加の考慮事項について説明します。
As mentioned in [RFC4761], there are two aspects to achieving data privacy and protecting against denial-of-service attacks in a VPLS: securing the control plane and protecting the forwarding path. Compromise of the control plane could result in a PE sending multicast data belonging to some VPLS to another VPLS, or black-holing VPLS multicast data, or even sending it to an eavesdropper; none of which are acceptable from a data privacy point of view. In addition, compromise of the control plane could result in black-holing VPLS multicast data and could provide opportunities for unauthorized VPLS multicast usage (e.g., exploiting traffic replication within a multicast tree to amplify a denial-of-service attack based on sending large amounts of traffic).
[RFC4761]で述べたように、VPLSでのデータプライバシーの実現とサービス拒否攻撃からの保護には、コントロールプレーンの保護と転送パスの保護の2つの側面があります。コントロールプレーンが侵害されると、PEが一部のVPLSに属するマルチキャストデータを別のVPLSに送信したり、VPLSマルチキャストデータをブラックホール化したり、さらには盗聴者に送信したりする可能性があります。データプライバシーの観点からは、どれも許容されません。さらに、コントロールプレーンの侵害により、VPLSマルチキャストデータがブラックホール化し、不正なVPLSマルチキャスト使用の機会がもたらされる可能性があります（たとえば、マルチキャストツリー内のトラフィックレプリケーションを悪用して、大量の送信に基づくサービス拒否攻撃を増幅する可能性があります）トラフィックの）。
The mechanisms in this document use BGP for the control plane. Hence, techniques such as in [RFC5925] help authenticate BGP messages, making it harder to spoof updates (which can be used to divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of-service attacks). In the multi-AS methods (b) and (c) described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section, this also means protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or the Route Reflectors.
このドキュメントのメカニズムでは、コントロールプレーンにBGPを使用しています。したがって、[RFC5925]などの手法は、BGPメッセージの認証に役立ち、更新（VPLSトラフィックを誤ったVPLSに迂回するために使用される可能性があります）または撤回（サービス拒否攻撃）を偽装することを困難にします。 「AS間のPマルチキャストツリーAD /バインディング」セクションで説明されているマルチAS方式（b）と（c）では、これはASBR、PE、またはAS間のAS間BGPセッションを保護することも意味します。ルートリフレクター。
Note that [RFC5925] will not help in keeping MPLS labels, associated with P2MP LSPs or the upstream MPLS labels used for aggregation, private -- knowing the labels, one can eavesdrop on VPLS traffic. However, this requires access to the data path within an SP network, which is assumed to be composed of trusted nodes/links.
[RFC5925]は、P2MP LSPまたはアグリゲーションに使用されるアップストリームMPLSラベルに関連付けられたMPLSラベルをプライベートに保つのに役立ちません。ラベルを知っていると、VPLSトラフィックを盗聴できます。ただし、これには、SPネットワーク内のデータパスへのアクセスが必要です。これは、信頼されたノード/リンクで構成されると想定されています。
One of the requirements for protecting the data plane is that the MPLS labels be accepted only from valid interfaces. This applies both to MPLS labels associated with P2MP LSPs and to the upstream-assigned MPLS labels. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise links from other routers in the ASBR's own AS, and links from other ASBRs in ASes that have instances of a given VPLS. It is especially important in the case of multi-AS VPLS instances that one accept VPLS packets only from valid interfaces.
データプレーンを保護するための要件の1つは、MPLSラベルが有効なインターフェイスからのみ受け入れられることです。これは、P2MP LSPに関連付けられたMPLSラベルと、アップストリームに割り当てられたMPLSラベルの両方に適用されます。 PEの場合、有効なインターフェイスは、PE自身のAS内の他のルーターからのリンクを構成します。 ASBRの場合、有効なインターフェースは、ASBR自体のAS内の他のルーターからのリンクと、特定のVPLSのインスタンスを持つAS内の他のASBRからのリンクで構成されます。マルチAS VPLSインスタンスの場合、有効なインターフェイスからのみVPLSパケットを受け入れることが特に重要です。
This document defines a new NLRI, called "MCAST-VPLS", to be carried in BGP using multiprotocol extensions. IANA has assigned it a SAFI value of 8.
このドキュメントでは、マルチプロトコル拡張を使用してBGPで伝送される「MCAST-VPLS」と呼ばれる新しいNLRIを定義します。 IANAはそれにSAFI値8を割り当てました。
This document defines a BGP-optional transitive attribute called "PMSI_TUNNEL". This is the same attribute as the one defined in [RFC6514] and the code point for this attribute has already been assigned by IANA as 22 [BGP-IANA]. Hence, no further action is required from IANA regarding this attribute.
このドキュメントでは、「PMSI_TUNNEL」と呼ばれるBGPオプションの推移属性を定義します。これは[RFC6514]で定義されているものと同じ属性であり、この属性のコードポイントはIANAによって22 [BGP-IANA]として既に割り当てられています。したがって、この属性に関してIANAからの追加のアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service（VPLS）Using BGP for Auto-Discovery and Signaling"、RFC 4761、2007年1月。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、2007年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.
[RFC6511] Ali、Z.、Swallow、G。、およびR. Aggarwal、「RSVP-TEラベルスイッチドパスの非最後から2番目のホップのポップ動作と帯域外マッピング」、RFC 6511、2012年2月。
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012.
[RFC6512] Wijnands、IJ。、Rosen、E.、Napierala、M。、およびN. Leymann、「バックボーンにルートへのルートがない場合のマルチポイントLDPの使用」、RFC 6512、2012年2月。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、2012年2月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、February 2012。
[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, November 2011.
[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、2011年11月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]ローゼン、E。、デービー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC5501] Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009.
[RFC5501] Kamite、Y.、Ed。、Wada、Y.、Serbest、Y.、Morin、T。、およびL. Fang、「仮想プライベートLANサービスでのマルチキャストサポートの要件」、RFC 5501、2009年3月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、2008年8月。
[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, November 2006.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月。
[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, May 2007.
[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、2007年5月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。、編、およびL. Costa、編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、2004年6月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[MULTI-HOMING] Kothari, B., Kompella, K., Henderickx, W., Balus, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013.
[マルチホーミング] Kothari、B.、Kompella、K.、Henderickx、W.、Balus、F.、Uttaro、J.、Palislamovic、S。、およびW. Lin、「仮想プライベートLANにおけるBGPベースのマルチホーミングサービス」、作業中、2013年7月。
[BGP-IANA] IANA, "Border Gateway Protocol (BGP) Parameters", <http://www.iana.org/assignments/bgp-parameters>.
[BGP-IANA] IANA、「Border Gateway Protocol（BGP）Parameters」、<http://www.iana.org/assignments/bgp-parameters>。
Many thanks to Thomas Morin for his support of this work.
この作業をサポートしてくれたThomas Morinに感謝します。
We would also like to thank authors of [RFC6514] and [RFC6513], as the details of the inter-AS segmented tree procedures in this document, as well as some text that describes these procedures have benefited from those in [RFC6514] and [RFC6513]. The same applies to the notion of Inclusive and Selective trees, as well as the procedures for switching from Inclusive to Selective trees.
また、[RFC6514]と[RFC6513]の作成者にも感謝します。このドキュメントのAS間セグメントツリー手順の詳細と、これらの手順を説明するテキストの一部は、[RFC6514]と[ RFC6513]。同じことが包含的ツリーと選択的ツリーの概念、および包含的ツリーから選択的ツリーに切り替える手順にも当てはまります。
We would also like to thank Nabil Bitar, Stewart Bryant, Wim Henderickx, and Eric Rosen for their review and comments.
また、Nabil Bitar、Stewart Bryant、Wim Henderickx、およびEric Rosenのレビューとコメントにも感謝します。
Authors' Addresses
著者のアドレス
Rahul Aggarwal 998 Lucky Avenue Menlo Park, CA 94025 USA Phone: +1-415-806-5527 EMail: raggarwa_1@yahoo.com
Rahul Aggarwal 998 Lucky Avenue Menlo Park、CA 94025 USA電話：+ 1-415-806-5527メール：raggarwa_1@yahoo.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく ときょ １０８ー８１１８ じゃぱん えまいｌ： ｙ。かみて＠んっｔ。こｍ
Luyuan Fang Microsoft EMail: lufang@microsoft.com
l U yuan f Ang Microsoft電子メール：record and place@Microsoft.com
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089 USA Eメール：yakov@juniper.net
Chaitanya Kodeboniya EMail: chaitk@yahoo.com
Chaitanya Kodeboniya Eメール：chaitk@yahoo.com