[要約] RFC 7988は、マルチキャストVPNにおけるイングレスレプリケーショントンネルに関する規格です。このRFCの目的は、マルチキャストVPNのネットワークでのイングレスレプリケーショントンネルの設定と運用に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 7988 Juniper Networks, Inc.
Updates: 6513, 6514 K. Subramanian
Category: Standards Track Sproute Networks
ISSN: 2070-1721 Z. Zhang
Juniper Networks, Inc.
October 2016
Ingress Replication Tunnels in Multicast VPN
マルチキャストVPNの入力レプリケーショントンネル
Abstract
概要
RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.
RFC 6513、6514、およびその他のRFCには、サービスプロバイダーがマルチキャストVPN（MVPN）サービスを顧客に提供する手順が記載されています。これらの手順により、サービスプロバイダーのバックボーン全体にポイントツーマルチポイント（P2MP）またはマルチポイントツーマルチポイント（MP2MP）ツリーが作成されます。使用できるP2MPツリーの1つのタイプは、「入力レプリケーション（IR）トンネル」と呼ばれます。 IRトンネルでは、親ノードを子ノードに直接接続する必要はありません。親ノードがn個の子ノードにマルチキャストデータパケットを送信する必要がある場合、親ノードはレイヤ2マルチキャスト、IPマルチキャスト、またはMPLSマルチキャストを使用して送信しません。代わりに、n個の個別のコピーを作成し、IPまたはMPLSユニキャストトンネルを介して、各コピーを1つの子ノードにユニキャストします。以前のMVPN仕様ではIRトンネルの使用が許可されていますが、これらの仕様は、MVPNプロトコル要素と手順がIRトンネルにどのように適用されるかについて、必ずしも非常に明確または明示的ではありません。このドキュメントは、IRトンネルの使用に固有の詳細を追加することにより、RFC 6513および6514を更新します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7988.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7988で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
3. How are IR P-tunnels identified? . . . . . . . . . . . . . . 7
4. How to Join an IR P-Tunnel . . . . . . . . . . . . . . . . . 9
4.1. Advertised IR P-Tunnels . . . . . . . . . . . . . . . . . 9
4.1.1. If the Leaf Information Required Bit Is Set . . . . . 10
4.1.2. If the Leaf Information Required Bit Is Not Set . . . 10
4.2. Unadvertised IR P-Tunnels . . . . . . . . . . . . . . . . 11
5. The PTA's Tunnel Identifier Field . . . . . . . . . . . . . . 11
6. A Note on IR P-Tunnels and Discarding Packets from the Wrong
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. The PTA's MPLS Label Field . . . . . . . . . . . . . . . . . 14
7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 16
7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
8. How A Child Node Prunes Itself from an IR P-Tunnel . . . . . 17
9. Parent Node Actions upon Receiving Leaf A-D Route . . . . . . 18
10. Use of Timers When Switching UMH . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider (SP) may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" (provider tunnels), across the SP's backbone network. Customer multicast traffic is carried through the P-tunnels.
RFC 6513、6514、およびその他のRFCは、サービスプロバイダー（SP）がマルチキャストVPN（MVPN）サービスを顧客に提供する手順を説明しています。これらの手順により、SPのバックボーンネットワーク全体に「Pトンネル」（プロバイダートンネル）と呼ばれるポイントツーマルチポイント（P2MP）またはマルチポイントツーマルチポイント（MP2MP）トンネルが作成されます。カスタマーマルチキャストトラフィックは、Pトンネルを介して伝送されます。
A number of different P-tunnel technologies are supported. One of the supported P-tunnel technologies is known as "ingress replication" or "unicast replication". We will use the acronym "IR" to refer to this P-tunnel technology.
多くの異なるPトンネルテクノロジーがサポートされています。サポートされているPトンネルテクノロジーの1つは、「入力レプリケーション」または「ユニキャストレプリケーション」と呼ばれています。このPトンネル技術を指すために頭字語「IR」を使用します。
An IR P-tunnel is a P2MP tree, but a given node on the tree is not necessarily directly attached to its parent node or to its child nodes. To send a multicast data packet from a parent node to one of its child nodes, the parent node encapsulates the packet and then unicasts it through a tunnel to the child node. The tunnel may be a P2P or MP2P MPLS LSP (Label Switched Path) or a unicast IP tunnel. If a node on an IR tree has n child nodes, and has a multicast data packet that must be sent along the tree, the parent node makes n individual copies of the data packet, and then sends each copy, through a unicast tunnel, to exactly one child node. No lower-layer multicast technology is used when sending traffic from a parent node to a child node; therefore, multiple copies of the packet may be sent out a single interface.
IR PトンネルはP2MPツリーですが、ツリー上の特定のノードは、必ずしもその親ノードまたは子ノードに直接接続されているとは限りません。親ノードから子ノードの1つにマルチキャストデータパケットを送信するには、親ノードがパケットをカプセル化してから、トンネルを介して子ノードにユニキャストします。トンネルは、P2PまたはMP2P MPLS LSP（ラベルスイッチドパス）またはユニキャストIPトンネルです。 IRツリー上のノードにn個の子ノードがあり、ツリーに沿って送信する必要があるマルチキャストデータパケットがある場合、親ノードはデータパケットのn個の個別のコピーを作成し、ユニキャストトンネルを介して各コピーを送信します。ちょうど1つの子ノード。親ノードから子ノードにトラフィックを送信する場合、下位層のマルチキャストテクノロジーは使用されません。したがって、パケットの複数のコピーが単一のインターフェイスから送信される場合があります。
With the single exception of IR, the P-tunnel technologies supported by the MVPN specifications are preexisting IP multicast or MPLS multicast technologies. Each such technology has its own set of specifications, its own setup and maintenance protocols, its own syntax for identifying specific multicast trees, and its own procedures for enabling a router to be added to or removed from a particular multicast tree. For IR P-tunnels, on the other hand, there is no prior specification for setting up and maintaining the P2MP trees; the procedures and protocol elements used for setting up and maintaining the P2MP trees are specified in the MVPN specifications themselves, and all the signaling/setup is done by using the BGP Auto-Discovery (A-D) routes that are defined in [RFC6514]. (The unicast tunnels used to transmit multicast data from one node to another in an IR P-tunnel may of course have their own setup and maintenance protocols, e.g., [RFC5036], [RFC3209].)
IRを除いて、MVPN仕様でサポートされているPトンネルテクノロジーは、既存のIPマルチキャストまたはMPLSマルチキャストテクノロジーです。そのような各テクノロジには、独自の仕様セット、独自のセットアップおよびメンテナンスプロトコル、特定のマルチキャストツリーを識別するための独自の構文、およびルーターを特定のマルチキャストツリーに追加または削除できるようにするための独自の手順があります。一方、IR Pトンネルの場合、P2MPツリーの設定と維持に関する以前の仕様はありません。 P2MPツリーのセットアップと維持に使用される手順とプロトコル要素は、MVPN仕様自体で指定されており、すべてのシグナリング/セットアップは、[RFC6514]で定義されているBGP Auto-Discovery（A-D）ルートを使用して行われます。 （もちろん、IR Pトンネル内のあるノードから別のノードにマルチキャストデータを送信するために使用されるユニキャストトンネルには、[RFC5036]、[RFC3209]などの独自のセットアップおよびメンテナンスプロトコルがあります。）
Since the transmission of a multicast data packet along an IR P-tunnel is done by transmitting the packet through a unicast tunnel, previous RFCs sometimes describe an IR P-tunnel as "consisting of" a set of unicast tunnels. However, that description is not quite accurate. For one thing, it obscures the fact that an IR P-tunnel is really a P2MP tree, whose nodes must maintain multicast state in both the control and data planes. For another, it obscures the fact the unicast tunnels used by a particular IR P-tunnel need not be specific to that P-tunnel; a single unicast tunnel can carry the multicast traffic of many different IR P-tunnels (and can also carry unicast traffic as well).
IR Pトンネルに沿ったマルチキャストデータパケットの送信はユニキャストトンネルを介してパケットを送信することによって行われるため、以前のRFCではIR Pトンネルを一連のユニキャストトンネルの「からなる」と記述している場合があります。ただし、その説明は正確ではありません。 1つには、IR Pトンネルは実際にはP2MPツリーであり、そのノードはコントロールプレーンとデータプレーンの両方でマルチキャスト状態を維持する必要があるという事実を覆い隠しています。また、特定のIR Pトンネルが使用するユニキャストトンネルは、そのPトンネルに固有である必要がないという事実を覆い隠しています。単一のユニキャストトンネルは、さまざまなIR Pトンネルのマルチキャストトラフィックを伝送できます（ユニキャストトラフィックも伝送できます）。
In this document, we provide a clearer and more explicit conceptual model for IR P-tunnels, clarifying the relationship between an IR P-tunnel and the unicast tunnels that are used for data transmission along the IR P-tunnel.
このドキュメントでは、IR Pトンネルのより明確で明確な概念モデルを提供し、IR PトンネルとIR Pトンネルに沿ったデータ伝送に使用されるユニキャストトンネルの関係を明らかにします。
Section 5 of [RFC6514] defines a BGP Path Attribute known as the "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA). This attribute contains a field known as the "Tunnel Identifier" field. For most P-tunnel technologies, the PTA's "Tunnel Identifier" field is used to identify a P-tunnel (i.e., to identify a P2MP or MP2MP tree). However, when IR P-tunnels are used, the PTA "Tunnel Identifier" field does not actually identify an IR P-tunnel. In some cases, it identifies one of the P-tunnel's constituent unicast tunnels; in other cases, it is not used to identify a tunnel at all. In this document, we provide an explicit specification for how IR P-tunnels are actually identified.
[RFC6514]のセクション5は、「PMSI（プロバイダーマルチキャストサービスインターフェイス）トンネル属性」（PTA）と呼ばれるBGPパス属性を定義しています。この属性には、「トンネル識別子」フィールドと呼ばれるフィールドが含まれています。ほとんどのPトンネル技術では、PTAの「トンネル識別子」フィールドを使用して、Pトンネルを識別します（つまり、P2MPまたはMP2MPツリーを識別します）。ただし、IR Pトンネルが使用されている場合、PTAの「トンネルID」フィールドは実際にはIR Pトンネルを識別しません。場合によっては、Pトンネルを構成するユニキャストトンネルの1つを識別します。それ以外の場合は、トンネルの識別にはまったく使用されません。このドキュメントでは、IR Pトンネルが実際に識別される方法の明示的な仕様を提供します。
Some of the MVPN specifications specify procedures that require a PE router to join the P-tunnel that has been identified in a particular MVPN route. However, up to now, there has not been an explicit specification of how to identify an IR P-tunnel, of how a router joins such a P-tunnel, or of how a router prunes itself from such a P-tunnel. In this document, we make these procedures more explicit.
一部のMVPN仕様では、特定のMVPNルートで識別されたPトンネルにPEルータが参加することを要求する手順を指定しています。ただし、これまで、IR Pトンネルを識別する方法、ルーターがそのようなPトンネルに参加する方法、またはルーターがそのようなPトンネルからそれ自体をプルーニングする方法の明確な仕様はありませんでした。このドキュメントでは、これらの手順をより明確にします。
[RFC6514] does provide a method for binding an MPLS label to a P-tunnel, but does not discuss the label allocation policies that are needed for correct operation when the P-tunnel is an IR P-tunnel. Those policies are discussed in this document.
[RFC6514]は、MPLSラベルをPトンネルにバインドする方法を提供しますが、PトンネルがIR Pトンネルである場合の正しい操作に必要なラベル割り当てポリシーについては説明しません。これらのポリシーについては、このドキュメントで説明しています。
This document does not provide any new protocol elements or any fundamentally new procedures; its purpose is to make explicit just how a router is to use the protocol elements and procedures of [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself from an IR P-tunnel.
このドキュメントでは、新しいプロトコル要素や根本的に新しい手順については説明していません。その目的は、ルーターが[RFC6513]と[RFC6514]のプロトコル要素と手順を使用してIR Pトンネルを識別し、IR Pトンネルに参加し、IR Pから自身をプルーニングする方法を明示することです-トンネル。
This document also discusses the MPLS label allocation policies that need to be supported when binding MPLS labels to IR P-tunnels, and the timer policies that need to be supported when switching a customer multicast flow from one IR P-tunnel to another. These are procedures that are not clearly specified in [RFC6513] or [RFC6514].
このドキュメントでは、MPLSラベルをIR Pトンネルにバインドするときにサポートする必要があるMPLSラベル割り当てポリシー、および顧客のマルチキャストフローをあるIR Pトンネルから別のIR Pトンネルに切り替えるときにサポートする必要があるタイマーポリシーについても説明します。これらは、[RFC6513]または[RFC6514]で明確に指定されていない手順です。
As the material in this document must be understood in order to properly implement IR P-tunnels, this document updates [RFC6513] and [RFC6514].
IR Pトンネルを適切に実装するには、このドキュメントの内容を理解する必要があるため、このドキュメントは[RFC6513]と[RFC6514]を更新します。
This document also discusses the application of "seamless multicast" [RFC7524] and "extranet" [RFC7900] procedures to IR P-tunnels.
このドキュメントでは、「シームレスマルチキャスト」[RFC7524]および「エクストラネット」[RFC7900]手順のIR Pトンネルへの適用についても説明します。
This document does not discuss the use of IR P-tunnels to support a VPN customer's use of Bidirectional Protocol Independent Multicast (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of [RFC6513], [RFC6514], and [RFC7582] so that a customer's use of BIDIR-PIM can be supported by IR P-tunnels.
このドキュメントでは、VPN顧客による双方向プロトコル独立マルチキャスト（BIDIR-PIM）の使用をサポートするためのIR Pトンネルの使用については説明していません。 [RFC7740]では、[RFC6513]、[RFC6514]、および[RFC7582]の手順を適合させて、顧客によるBIDIR-PIMの使用をIR Pトンネルでサポートできるようにする方法について説明しています。
In the event of any conflict between this document and either [RFC6513] or [RFC6514], this document takes precedence.
このドキュメントと[RFC6513]または[RFC6514]のいずれかとの間に矛盾がある場合、このドキュメントが優先されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when and only when appearing in all capital letters, are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL "、すべて大文字で現れる場合に限り、[RFC2119]で説明されているように解釈されます。
An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that support the MVPN procedures of [RFC6514] and related RFCs. In general, the nodes of an IR P-tunnel are either Provider Edge (PE) routers, Autonomous System Border Routers (ASBRs), or (if [RFC7524] is supported) Area Border Routers (ABRs). (MVPN procedures are sometimes used to support non-MVPN, or "global table" multicast; one way of doing this is defined in [RFC7524]. Another way is defined in [RFC7716]. In such cases, IR P-tunnels can be used outside the context of MVPN.)
IR PトンネルはP2MPツリーです。そのノードは、[RFC6514]のMVPN手順と関連するRFCをサポートするBGPスピーカーです。一般に、IR Pトンネルのノードは、プロバイダーエッジ（PE）ルーター、自律システムボーダールーター（ASBR）、または（[RFC7524]がサポートされている場合）エリアボーダールーター（ABR）のいずれかです。 （MVPNプロシージャは、非MVPNまたは「グローバルテーブル」マルチキャストをサポートするために使用されることがあります。これを行う1つの方法は[RFC7524]で定義されています。別の方法は[RFC7716]で定義されています。このような場合、IR PトンネルはMVPNのコンテキスト外で使用されます。）
MVPN P-tunnels may be either "segmented" or "non-segmented" (as these terms are defined in [RFC6513] and [RFC6514]).
MVPN Pトンネルは、「セグメント化」または「非セグメント化」のいずれかです（これらの用語は[RFC6513]および[RFC6514]で定義されているため）。
A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting only of a root node and a set of nodes that are children of the root node. When used in an MVPN context, the root is an ingress PE, and the child nodes of the root are the egress PEs.
「非セグメント化」IR Pトンネルは、2つのレベルのP2MPツリーであり、ルートノードと、ルートノードの子であるノードのセットのみで構成されます。 MVPNコンテキストで使用される場合、ルートは入力PEであり、ルートの子ノードは出力PEです。
In a segmented P-tunnel, IR may be used for some or all of the segments. If a particular segment of a segmented P-tunnel uses IR, then the root of that segment may have child nodes that are ABRs or ASBRs, rather than egress PEs.
セグメント化されたPトンネルでは、IRはセグメントの一部またはすべてに使用できます。セグメント化されたPトンネルの特定のセグメントがIRを使用する場合、そのセグメントのルートには、出力PEではなく、ABRまたはASBRである子ノードが含まれている可能性があります。
As with any type of P2MP tree, each node of an IR P-tunnel holds "multicast state" for the P-tunnel. That is, each node knows the identity of its parent node on the tree, and each node knows the identities of its child nodes on the tree. In the MVPN specs, the "parent" node is also known as the "Upstream Multicast Hop" or "UMH". Note that the UMH may be a PE, an ASBR, or (if procedures from [RFC7524] are being used) an ABR. (In [RFC7524], the term "upstream node" is used instead of "UMH".)
他のタイプのP2MPツリーと同様に、IR Pトンネルの各ノードはPトンネルの「マルチキャスト状態」を保持します。つまり、各ノードはツリー上の親ノードのIDを知っており、各ノードはツリー上の子ノードのIDを知っています。 MVPN仕様では、「親」ノードは「アップストリームマルチキャストホップ」または「UMH」とも呼ばれます。 UMHはPE、ASBR、または（[RFC7524]からの手順が使用されている場合）ABRである可能性があることに注意してください。 （[RFC7524]では、「UMH」の代わりに「上流ノード」という用語が使用されます。）
What distinguishes an IR P-tunnel from any other kind of P2MP tree is the method by which a data packet is transmitted from a parent node to a child node. To transmit a multicast data packet from a parent node to a child node along a particular IR P-tunnel, the parent node does the following:
IR Pトンネルを他の種類のP2MPツリーと区別するのは、データパケットを親ノードから子ノードに送信する方法です。マルチキャストデータパケットを特定のIR Pトンネルに沿って親ノードから子ノードに送信するために、親ノードは次のことを行います。
o It labels the packet with a label (call it a "P-tunnel label") that the child node has assigned to that P-tunnel.
o 子ノードがそのPトンネルに割り当てたラベル（「Pトンネルラベル」と呼びます）でパケットにラベルを付けます。
o It then places the packet in a unicast encapsulation and unicasts the packet to the child node. That is, the parent node sends the packet through a unicast tunnel to a particular child node. This unicast tunnel need not be specially created to be part of the IR P-tunnel; it can be any P2P or MP2P unicast tunnel that will get the packets from the parent node to the child node. A single such unicast tunnel may be carrying multicast data packets of several different P2MP trees and may also be carrying unicast data packets.
o 次に、パケットをユニキャストカプセル化し、パケットを子ノードにユニキャストします。つまり、親ノードはユニキャストトンネルを介してパケットを特定の子ノードに送信します。このユニキャストトンネルをIR Pトンネルの一部にするために特別に作成する必要はありません。これは、親ノードから子ノードにパケットを取得する任意のP2PまたはMP2Pユニキャストトンネルにすることができます。単一のそのようなユニキャストトンネルは、いくつかの異なるP2MPツリーのマルチキャストデータパケットを運ぶことができ、ユニキャストデータパケットを運ぶこともできます。
The parent node repeats this process for each child node, creating one copy for each child node, and sending each copy through a unicast tunnel to corresponding child node. It does not use Layer 2 multicast, IP multicast, or MPLS multicast to transmit packets to its child nodes. As a result, multiple copies of each packet may be sent out a single interface; this may happen, e.g., if that interface is the next-hop interface, according to unicast routing, from the parent node to several of the child nodes.
親ノードは、子ノードごとにこのプロセスを繰り返し、子ノードごとに1つのコピーを作成し、各コピーをユニキャストトンネルを介して対応する子ノードに送信します。パケットを子ノードに送信するために、レイヤー2マルチキャスト、IPマルチキャスト、またはMPLSマルチキャストを使用しません。その結果、各パケットの複数のコピーが単一のインターフェースに送信される可能性があります。これは、たとえば、そのインターフェースが、ユニキャストルーティングに従って、親ノードからいくつかの子ノードへのネクストホップインターフェースである場合に発生する可能性があります。
Since data traveling along an IR P-tunnel is always unicast from parent node to child node, it can be convenient to think of an IR P-tunnel as a P2MP tree whose arcs are unicast tunnels. However, it is important to understand that the unicast tunnels need not be specific to any particular IR P-tunnel. If R1 is the parent node of R2 on two different IR P-tunnels, a single unicast tunnel from R1 to R2 may be used to carry data along both IR P-tunnels. All that is required is that when the data packets arrive at R2, R2 will see the "P-tunnel label" at the top of the packets' label stack; R2's further processing of the packets will depend upon that label. Note that the same unicast tunnel between R1 and R2 may also be carrying unicast data packets.
IR Pトンネルに沿って移動するデータは常に親ノードから子ノードにユニキャストされるため、IR PトンネルをアークがユニキャストトンネルであるP2MPツリーと考えると便利です。ただし、ユニキャストトンネルは特定のIR Pトンネルに固有である必要はないことを理解することが重要です。 R1が2つの異なるIR Pトンネル上のR2の親ノードである場合、R1からR2への単一のユニキャストトンネルを使用して、両方のIR Pトンネルに沿ってデータを伝送できます。必要なことは、データパケットがR2に到着すると、R2はパケットのラベルスタックの最上部にある「Pトンネルラベル」を見るということです。 R2がパケットをさらに処理するかどうかは、そのラベルに依存します。 R1とR2の間の同じユニキャストトンネルもユニキャストデータパケットを伝送している可能性があることに注意してください。
Typically, the unicast tunnels are the LSPs that already exist to carry unicast traffic; either MP2P LSPs created by the Label Distribution Protocol (LDP) [RFC5036] or P2P LSPs created by Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209]. However, any other kind of unicast tunnel may be used. A unicast tunnel may have an arbitrary number of intermediate routers; those routers do not maintain any multicast state for the IR P-tunnel and, in general, are not even aware of its existence.
通常、ユニキャストトンネルは、ユニキャストトラフィックを伝送するためにすでに存在するLSPです。ラベル配布プロトコル（LDP）[RFC5036]によって作成されたMP2P LSP、またはリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）[RFC3209]によって作成されたP2P LSP。ただし、他の種類のユニキャストトンネルを使用できます。ユニキャストトンネルには、任意の数の中間ルーターを含めることができます。これらのルーターは、IR Pトンネルのマルチキャスト状態を維持せず、一般に、その存在を認識していません。
As with all other P-tunnel types, an IR P-tunnel may be used to instantiate either an Inclusive PMSI (I-PMSI) or a Selective PMSI (S-PMSI). See Section 3.2 of [RFC6513] for an explanation of those concepts.
他のすべてのPトンネルタイプと同様に、IR Pトンネルは、包括的PMSI（I-PMSI）または選択的PMSI（S-PMSI）のいずれかをインスタンス化するために使用できます。これらの概念の説明については、[RFC6513]のセクション3.2をご覧ください。
There are four MVPN BGP route types in which P-tunnels can be identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf A-D routes. (These route types are all defined in [RFC6514]).
Pトンネルを識別できる4つのMVPN BGPルートタイプがあります。AS内I-PMSI A-Dルート、AS間I-PMSI A-Dルート、S-PMSI A-Dルート、およびリーフA-Dルートです。 （これらのルートタイプはすべて[RFC6514]で定義されています）。
Whenever it is necessary to identify a P-tunnel in a route of one of these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. As defined in Section 5 of [RFC6514], the PTA contains four fields: Tunnel Type, MPLS Label, Tunnel Identifier, and Flags. [RFC6514] defines only one bit in the Flags field, the Leaf Information Required bit.
これらのタイプのいずれかのルートでPトンネルを識別する必要がある場合はいつでも、「PMSIトンネル属性」（PTA）がルートに追加されます。 [RFC6514]のセクション5で定義されているように、PTAには4つのフィールドがあります。トンネルタイプ、MPLSラベル、トンネル識別子、フラグです。 [RFC6514]は、Flagsフィールドで1つのビット、Leaf Information Requiredビットのみを定義します。
If a route identifies an IR P-tunnel, the Tunnel Type field of its PTA is set to the value 6, meaning "Ingress Replication".
ルートがIR P-tunnelを識別する場合、そのPTAのTunnel Typeフィールドは値6に設定され、「Ingress Replication」を意味します。
Most types of P-tunnel are associated with specific protocols that are used to set up and maintain tunnels of that type. For example, if the Tunnel Type field is set to 2, meaning "mLDP P2MP LSP", the associated setup protocol is Multipoint LDP (mLDP) [RFC6388]. The associated setup protocol always has a method of identifying the tunnels that it sets up. For example, mLDP uses an FEC element (Forwarding Equivalence Class element) to identify a tree. If the Tunnel Type field is set to 3, meaning "PIM-SSM Tree", where "SSM" stands for Source-Specific Multicast, the associated setup protocol is PIM, and "(S,G)" is used to identify the tree. In these cases, the Tunnel Identifier field of the PTA carries a tree identifier as defined by the setup protocol used for the particular tunnel type.
ほとんどのタイプのPトンネルは、そのタイプのトンネルのセットアップと維持に使用される特定のプロトコルに関連付けられています。たとえば、トンネルタイプフィールドが「mLDP P2MP LSP」を意味する2に設定されている場合、関連付けられているセットアッププロトコルはMultipoint LDP（mLDP）[RFC6388]です。関連するセットアッププロトコルには、セットアップするトンネルを識別する方法が常にあります。たとえば、mLDPはFEC要素（Forwarding Equivalence Class要素）を使用してツリーを識別します。トンネルタイプフィールドが3に設定されている場合、「PIM-SSMツリー」を意味します。「SSM」は送信元固有のマルチキャストを表し、関連するセットアッププロトコルはPIMであり、「（S、G）」はツリーの識別に使用されます。これらの場合、PTAのTunnel Identifierフィールドには、特定のトンネルタイプに使用されるセットアッププロトコルで定義されたツリー識別子が含まれます。
IR P-tunnels, on the other hand, are entirely setup and maintained by the use of BGP A-D routes and are not associated with any other setup protocol. (The unicast tunnels used to transmit multicast data along an IR P-tunnel may have their own setup and maintenance protocols, of course.) The means of identifying a P-tunnel is very different for IR P-tunnels than for other types of P-tunnel:
一方、IR Pトンネルは、BGP A-Dルートを使用して完全にセットアップおよび維持され、他のセットアッププロトコルには関連付けられていません。 （もちろん、IR Pトンネルに沿ってマルチキャストデータを送信するために使用されるユニキャストトンネルは、独自のセットアッププロトコルとメンテナンスプロトコルを持っている場合があります。）Pトンネルを識別する方法は、IR Pトンネルと他のタイプのPトンネルでは非常に異なります。 -トンネル：
When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to these three route types as "advertising A-D routes"), its identifier is hereby defined to be the NLRI (Network Layer Reachability Information) of that route. See Sections 4.1, 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. Note that the IR P-tunnel identifier includes the Route Type and Length fields (see Section 4 of [RFC6514]) of the NLRI.
IR PトンネルがS-PMSI ADルート、Intra-AS I-PMSI ADルート、またはInter-AS I-PMSI ADルートで識別される場合（これらの3つのルートタイプを「広告ADルート」と呼びます。 "）、その識別子は、そのルートのNLRI（ネットワーク層到達可能性情報）としてここに定義されます。これらのNLRIの仕様については、[RFC6514]のセクション4.1、4.2、および4.3を参照してください。 IR Pトンネル識別子には、NLRIのルートタイプフィールドと長さフィールド（[RFC6514]のセクション4を参照）が含まれていることに注意してください。
To reiterate:
繰り返します：
The identifier of the IR P-tunnel does not appear in the PTA at all; the Tunnel Identifier field of the PTA does not contain the identifier of the IR P-tunnel.
IR Pトンネルの識別子はPTAにまったく表示されません。 PTAのトンネル識別子フィールドには、IR Pトンネルの識別子が含まれていません。
Rather, the identifier of the IR P-tunnel appears in the Network Layer Reachability Information (NLRI) field of the A-D routes that are used to advertise and to setup the IR P-tunnel.
むしろ、IR Pトンネルの識別子は、アドバタイズとIR Pトンネルのセットアップに使用されるA-Dルートのネットワーク層到達可能性情報（NLRI）フィールドに表示されます。
Note that an advertising A-D route is considered to identify an IR P-tunnel only if it carries a PTA whose Tunnel Type field is set to "IR".
アドバタイズA-Dルートは、Tunnel Typeフィールドが「IR」に設定されているPTAを伝送する場合にのみ、IR Pトンネルを識別すると見なされることに注意してください。
When an IR P-tunnel is identified in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route, the Leaf Information Required bit of the Flags field of the PTA MUST be set.
IR PトンネルがS-PMSI A-DルートまたはInter-AS I-PMSI A-Dルートで識別される場合、PTAのフラグフィールドのLeaf Information Requiredビットを設定する必要があります。
In an advertising A-D route:
広告A-Dルートの場合：
o If the Leaf Information Required bit of the Flags field of the PTA is set, then the Tunnel Identifier field of the PTA has no significance whatsoever and MUST be ignored upon reception.
o PTAのFlagsフィールドのLeaf Information Requiredビットが設定されている場合、PTAのTunnel Identifierフィールドは何の意味も持たず、受信時に無視する必要があります。
Note that, per RFC 6514, the length of the Tunnel Identifier field of the PTA is variable and is inferred from the length of the PTA. Even when this field is of no significance, its length MUST be the length of an IP address in the address space of the SP's backbone, as specified in Section 4.2 of [RFC6515]. In this case, it is RECOMMENDED that it be set to a routable address of the router that constructed the PTA. (While it might make more sense to allow or even require the field to be omitted entirely, that might raise issues of backwards compatibility with implementations that were designed prior to the publication of this document.)
RFC 6514に従い、PTAのトンネル識別子フィールドの長さは可変であり、PTAの長さから推測されることに注意してください。このフィールドに意味がない場合でも、[RFC6515]のセクション4.2で指定されているように、その長さはSPのバックボーンのアドレススペース内のIPアドレスの長さである必要があります。この場合、PTAを構築したルーターのルーティング可能なアドレスに設定することをお勧めします。 （フィールドを完全に省略することを許可または要求する方が理にかなっているかもしれませんが、このドキュメントの公開前に設計された実装との下位互換性の問題が発生する可能性があります。）
o If the Leaf Information Required bit is not set, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5 of this document.
o Leaf Information Requiredビットが設定されていない場合、PTAのTunnel Identifierフィールドは重要ですが、IR Pトンネルを識別しません。この場合のPTAのトンネル識別子フィールドの使用については、このドキュメントのセクション5で説明します。
Note that according to the above definition, there is no way for two different advertising A-D routes (i.e., two advertising A-D routes with different NLRIs) to advertise the same IR P-tunnel. In the terminology of [RFC6513], an IR P-tunnel can instantiate only a single PMSI. If an ingress PE, for example, wants to bind two customer multicast flows to a single IR P-tunnel, it must advertise that IR P-tunnel either in an I-PMSI A-D route or in an S-PMSI A-D route whose NLRI contains wildcards [RFC6625].
上記の定義によれば、2つの異なるアドバタイジングA-Dルート（つまり、NLRIが異なる2つのアドバタイジングA-Dルート）が同じIR Pトンネルをアドバタイズする方法はないことに注意してください。 [RFC6513]の用語では、IR Pトンネルは単一のPMSIのみをインスタンス化できます。たとえば、入力PEが2つのカスタマーマルチキャストフローを1つのIR Pトンネルにバインドする場合、そのIR Pトンネルを、NLRIが含まれるI-PMSI ADルートまたはS-PMSI ADルートでアドバタイズする必要があります。ワイルドカード[RFC6625]。
When an IR P-tunnel is identified in a Leaf A-D route, its identifier is the Route Key field of the route's NLRI. See Section 4.4 of [RFC6514].
IR PトンネルがリーフA-Dルートで識別される場合、その識別子はルートのNLRIのルートキーフィールドです。 [RFC6514]のセクション4.4をご覧ください。
A Leaf A-D route is considered to identify an IR P-tunnel only if it carries a PTA whose Tunnel Type field is set to "IR". In this type of route, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5.
リーフA-Dルートは、トンネルタイプフィールドが「IR」に設定されているPTAを伝送する場合にのみ、IR Pトンネルを識別すると見なされます。このタイプのルートでは、PTAのTunnel Identifierフィールドは重要ですが、IR Pトンネルを識別しません。この場合のPTAのトンネル識別子フィールドの使用については、セクション5で説明します。
The procedures for joining an IR P-tunnel depend upon whether the P-tunnel has been previously advertised, and, if so, upon how the P-tunnel was advertised. Note that joining an unadvertised IR P-tunnel is only possible when using the "global table multicast" procedures of [RFC7524].
IR Pトンネルに参加するための手順は、Pトンネルが以前にアドバタイズされているかどうか、およびそうである場合は、Pトンネルがどのようにアドバタイズされたかに依存します。アドバタイズされていないIR Pトンネルへの参加は、[RFC7524]の「グローバルテーブルマルチキャスト」手順を使用する場合にのみ可能であることに注意してください。
The procedures in this section apply when the IR P-tunnel to be joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route.
このセクションの手順は、参加するIR PトンネルがS-PMSI A-Dルート、Inter-AS I-PMSI A-Dルート、またはIntra-AS I-PMSI A-Dルートでアドバタイズされている場合に適用されます。
The procedures for joining an advertised IR P-tunnel depend upon whether the A-D route that advertises the IR P-tunnel has the Leaf Information Required bit set in its PTA.
アドバタイズされたIR Pトンネルに参加するための手順は、IR PトンネルをアドバタイズするA-DルートのPTAにLeaf Information Requiredビットが設定されているかどうかによって異なります。
The procedures in this section apply when the P-tunnel to be joined has been advertised in a route whose PTA has the Leaf Information Required bit set.
このセクションの手順は、参加するPトンネルが、PTAにLeaf Information Requiredビットが設定されているルートでアドバタイズされている場合に適用されます。
The router joining a particular IR P-tunnel must determine its UMH for that P-tunnel. If the route that advertised the IR P-tunnel contains a P2MP Segmented Next Hop Extended Community, the UMH is determined from the value of this community (see [RFC7524]). Otherwise, the UMH is determined from the route's next hop (see [RFC6514]).
特定のIR Pトンネルに参加するルーターは、そのPトンネルのUMHを決定する必要があります。 IR PトンネルをアドバタイズしたルートにP2MPセグメント化ネクストホップ拡張コミュニティが含まれている場合、UMHはこのコミュニティの値から決定されます（[RFC7524]を参照）。それ以外の場合、UMHはルートのネクストホップから決定されます（[RFC6514]を参照）。
Once the UMH is determined, the router joining the IR P-tunnel originates a Leaf A-D route. The NLRI of the Leaf A-D route is formed following the procedures of [RFC6514]. As a result, the NLRI of the Leaf A-D route will contain the IR P-tunnel identifier defined in Section 3 above as its "route key". The UMH MUST be identified by attaching an "IP-address-specific Route Target" (or an "IPv6-address-specific Route Target") to the Leaf A-D route. The IP address of the UMH appears in the Global Administrator field of the Route Target (RT). Details can be found in [RFC6514] and [RFC7524].
UMHが決定されると、IR Pトンネルに参加するルーターはリーフA-Dルートを発信します。リーフA-DルートのNLRIは、[RFC6514]の手順に従って形成されます。その結果、リーフA-DルートのNLRIには、上記のセクション3で定義されたIR Pトンネル識別子が「ルートキー」として含まれます。 UMHは、「IPアドレス固有のルートターゲット」（または「IPv6アドレス固有のルートターゲット」）をリーフA-Dルートにアタッチすることによって識別される必要があります。 UMHのIPアドレスは、ルートターゲット（RT）のグローバル管理者フィールドに表示されます。詳細は[RFC6514]と[RFC7524]にあります。
The Leaf A-D route MUST also contain a PTA whose fields are set as follows:
リーフA-Dルートには、フィールドが次のように設定されているPTAも含まれている必要があります。
o The Tunnel Type field is set to "IR".
o Tunnel Typeフィールドは「IR」に設定されています。
o The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel Identifier that is defined in Section 3.)
o Tunnel Identifierフィールドは、このドキュメントのセクション5で説明されているように設定されます。 （このフィールドには、セクション3で定義されているIR Pトンネル識別子が含まれていないことに注意してください。）
o The MPLS Label field is set to a non-zero value. This is the "P-tunnel label". The value must be chosen so as to satisfy various constraints, as discussed in Section 7 this document.
o MPLSラベルフィールドがゼロ以外の値に設定されています。これが「Pトンネルラベル」です。このドキュメントのセクション7で説明するように、さまざまな制約を満たすように値を選択する必要があります。
The procedures in this section apply when the IR P-tunnel to be joined has been advertised in a route whose PTA does not have the Leaf Information Required bit set. This can only be the case if the IR P-tunnel was advertised in an Intra-AS I-PMSI A-D route.
このセクションの手順は、参加するIR Pトンネルが、PTAにLeaf Information Requiredビットが設定されていないルートでアドバタイズされた場合に適用されます。これは、IR PトンネルがIntra-AS I-PMSI A-Dルートでアドバタイズされた場合にのみ該当します。
If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can be thought of as being instantiated by a set of IR P-tunnels. Each PE is the root of one such IR P-tunnel, and the other PEs are children of the root. A PE simultaneously joins all these P-tunnels by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D route with a PTA whose fields are set as follows:
IR Pトンネルが、特定のMVPNのPEルーターから発信されたIntra-AS I-PMSI ADルートでアドバタイズされる場合、Intra-AS I-PMSIは、一連のIR Pトンネルによってインスタンス化されていると考えることができます。 。各PEはそのような1つのIR Pトンネルのルートであり、他のPEはルートの子です。 PEは、フィールドが次のように設定されているPTAを使用して、AS内のI-PMSI A-Dルートを開始する（まだ行っていない場合）ことにより、これらすべてのPトンネルに同時に参加します。
o The Tunnel Type field is set to "IR".
o Tunnel Typeフィールドは「IR」に設定されています。
o The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel identifier that is defined in Section 3.)
o Tunnel Identifierフィールドは、このドキュメントのセクション5で説明されているように設定されます。 （このフィールドには、セクション3で定義されているIR Pトンネル識別子が含まれていないことに注意してください。）
o The MPLS Label field MUST be set to a non-zero value. This label value will be used by the child node to associate a received packet with the I-PMSI of a particular MVPN. The MPLS label allocation policy must be such as to ensure that the binding from label to I-PMSI is one to one.
o MPLSラベルフィールドはゼロ以外の値に設定する必要があります。このラベル値は、受信したパケットを特定のMVPNのI-PMSIに関連付けるために子ノードによって使用されます。 MPLSラベル割り当てポリシーは、ラベルからI-PMSIへのバインディングが1対1になるようにする必要があります。
The NLRI and the RTs of the originated I-PMSI A-D route are set as specified in [RFC6514].
発信されたI-PMSI A-DルートのNLRIおよびRTは、[RFC6514]で指定されているように設定されます。
In [RFC7524], a procedure is defined for "global table multicast", in which a P-tunnel can be joined even if the P-tunnel has not been previously advertised. See Sections 6.2.2 and 6.2.3 of [RFC7524]: "Leaf A-D Route for Global Table Multicast" and "Constructing the Rest of the Leaf A-D Route". The route key of the Leaf A-D route has the form of the "S-PMSI Route-Type Specific NLRI" (see Section 4.3 of [RFC6514]) in this case, and that should be considered to be the IR P-tunnel identifier. Note that the procedure for finding the UMH is different in this case; the UMH is the next hop of the best UMH-eligible route towards the "ingress PE". See Section 6.1 of [RFC7524], entitled "Determining the Upstream ABR/PE/ASBR (Upstream Node)".
[RFC7524]では、「グローバルテーブルマルチキャスト」の手順が定義されています。この手順では、Pトンネルが以前にアドバタイズされていなくても、Pトンネルに参加できます。 [RFC7524]のセクション6.2.2および6.2.3：「グローバルテーブルマルチキャスト用のリーフA-Dルート」および「リーフA-Dルートの残りの構成」を参照してください。この場合、リーフA-Dルートのルートキーの形式は「S-PMSIルートタイプ固有のNLRI」（[RFC6514]のセクション4.3を参照）であり、これはIR Pトンネル識別子と見なされます。この場合、UMHを見つける手順が異なることに注意してください。 UMHは、「入力PE」に向かう、UMHに適格な最良ルートのネクストホップです。 [RFC7524]のセクション6.1の「Determining the Upstream ABR / PE / ASBR（Upstream Node）」というタイトルのセクションを参照してください。
As discussed in Section 1, when the Tunnel Type field of a PTA is set to "IR", the Tunnel Identifier field of that PTA does not contain the IR P-tunnel identifier. This section specifies the procedures for setting the Tunnel Identifier field of the PTA when the Tunnel Type field of the PTA is set to "IR".
セクション1で説明したように、PTAのトンネルタイプフィールドが「IR」に設定されている場合、そのPTAのトンネル識別子フィールドにはIR Pトンネル識別子が含まれていません。このセクションでは、PTAのTunnel Typeフィールドが「IR」に設定されている場合に、PTAのTunnel Identifierフィールドを設定する手順を示します。
If the Tunnel Type field of a PTA is set to "IR", its Tunnel Identifier field is significant only when one of the following two conditions holds:
PTAのTunnel Typeフィールドが「IR」に設定されている場合、そのTunnel Identifierフィールドは、次の2つの条件のいずれかが当てはまる場合にのみ有効です。
o The PTA is carried by a Leaf A-D route, or
o PTAはLeaf A-Dルートで運ばれます、または
o The Leaf Information Required bit of the Flags field of the PTA is not set.
o PTAのFlagsフィールドのLeaf Information Requiredビットが設定されていません。
If one of these conditions holds, then the Tunnel Identifier field must contain a routable IP address of the originator of the route. (See Sections 9.2.3.2.1 and 9.2.3.4.1 of [RFC6514] for the detailed specification of the contents of this field.) This address is used by the UMH to determine the unicast tunnel that it will use in order to send data, along the IR P-tunnel identified by the route key, to the originator of the Leaf A-D route.
これらの条件のいずれかに当てはまる場合、トンネル識別子フィールドには、ルートの発信元のルーティング可能なIPアドレスが含まれている必要があります。 （このフィールドの内容の詳細な仕様については、[RFC6514]のセクション9.2.3.2.1および9.2.3.4.1を参照してください。）このアドレスは、UMHが送信に使用するユニキャストトンネルを決定するために使用されます。ルートキーによって識別されたIR Pトンネルに沿って、Leaf ADルートの発信者へのデータ。
The means by which the unicast tunnel is determined from this IP address is outside the scope of this document. The means by which the unicast tunnel is set up and maintained is also outside the scope of this document.
このIPアドレスからユニキャストトンネルを決定する方法は、このドキュメントの範囲外です。ユニキャストトンネルを設定および維持する方法も、このドキュメントの範囲外です。
Section 4 of [RFC6515] MUST be applied when a PTA is carried in a Leaf A-D route. It describes how to determine whether the Tunnel Identifier field carries an IPv4 or an IPv6 address.
[RFC6515]のセクション4は、PTAがリーフA-Dルートで運ばれる場合に適用する必要があります。 Tunnel IdentifierフィールドがIPv4またはIPv6アドレスを運ぶかどうかを判断する方法について説明します。
If neither of the above conditions hold, then the Tunnel Identifier field is of no significance and MUST be ignored upon reception.
上記のいずれの条件も満たさない場合、トンネル識別子フィールドは重要ではなく、受信時に無視する必要があります。
Section 9.1.1 of [RFC6513] specifies a procedure known as "Discarding Packets from the Wrong PE". When an egress PE receives a multicast data packet, this procedure requires it to determine the packet's ingress PE.
[RFC6513]のセクション9.1.1は、「間違ったPEからのパケットの破棄」と呼ばれる手順を指定しています。出力PEがマルチキャストデータパケットを受信すると、この手順では、パケットの入力PEを判別する必要があります。
In this document, we assume that when a packet has reached an egress PE via an IR P-tunnel, the egress PE will infer the identity of the packet's ingress PE by examining the packet's P-tunnel label.
このドキュメントでは、パケットがIR Pトンネルを介して出力PEに到達したときに、出力PEがパケットのPトンネルラベルを調べてパケットの入力PEのIDを推測すると想定しています。
Section 7 specifies certain constraints on the way in which the P-tunnel label is allocated for a given P-tunnel. In general, if these constraints are followed, an egress PE will be able to infer the identity of a packet's ingress PE from the P-tunnel label, and hence will be able to apply the procedures of Section 9.1.1 of [RFC6513]. This method of identifying a packet's ingress PE works exactly the same when the unicast tunnels are IP tunnels as it does when the unicast tunnels are MPLS LSPs.
セクション7は、Pトンネルラベルが特定のPトンネルに割り当てられる方法に関する特定の制約を指定します。一般に、これらの制約に従う場合、出力PEはPトンネルラベルからパケットの入力PEのIDを推測できるため、[RFC6513]のセクション9.1.1の手順を適用できます。パケットの入力PEを識別するこの方法は、ユニキャストトンネルがIPトンネルの場合も、ユニキャストトンネルがMPLS LSPの場合とまったく同じように機能します。
However, if the egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, then when the egress PE receives a packet through that P-tunnel, it will not be able to infer the identity of the packet's ingress PE from the P-tunnel label, and thus will not be able to apply the procedures of Section 9.1.1 of [RFC6513].
ただし、出力PEがセクション4.1.2の手順を使用して特定のIR Pトンネルに参加した場合、出力PEがそのPトンネルを介してパケットを受信すると、パケットの入力PEのIDを推測できません。 Pトンネルラベルから、したがって、[RFC6513]のセクション9.1.1の手順を適用できません。
One might think that if a particular IR P-tunnel uses IP unicast tunnels rather than MPLS LSPs, an egress PE could identify the ingress PE by inspecting the IP source address field of the encapsulating IP header. However, there are several reasons why this procedure is not desirable:
特定のIR PトンネルがMPLS LSPではなくIPユニキャストトンネルを使用する場合、出力PEはカプセル化IPヘッダーのIP送信元アドレスフィールドを検査することで入力PEを識別できると考えるかもしれません。ただし、この手順が望ましくない理由はいくつかあります。
o When segmented P-tunnels are being used, the IP source address field of the encapsulating IP header might not contain the address of the ingress PE.
o セグメント化されたPトンネルが使用されている場合、カプセル化IPヘッダーのIP送信元アドレスフィールドには、入力PEのアドレスが含まれていない可能性があります。
o Even if the IP source address field of the encapsulating IP header does identify the ingress PE, there is no guarantee that the IP source address in that header is the same as the IP address used by the ingress PE for the MVPN signaling procedures.
o カプセル化IPヘッダーのIP送信元アドレスフィールドが入力PEを識別しても、そのヘッダーのIP送信元アドレスが、入力VPNがMVPNシグナリング手順で使用するIPアドレスと同じである保証はありません。
o To apply the procedures of Section 9.1.1 of [RFC6513] when extranet functionality [RFC7900] is supported, it is necessary to infer a packet's ingress VRF (Virtual Routing and Forwarding table), not merely its ingress PE. This can be inferred from the P-tunnel label (assuming that the label is allocated following the procedures of Section 7), but it cannot be inferred from the IP source address of the encapsulating IP header.
o エクストラネット機能[RFC7900]がサポートされている場合に[RFC6513]のセクション9.1.1の手順を適用するには、パケットの入力PEだけでなく、パケットの入力VRF（仮想ルーティングおよび転送テーブル）を推測する必要があります。これは、Pトンネルラベルから推測できます（セクション7の手順に従ってラベルが割り当てられている場合）。ただし、カプセル化IPヘッダーのIP送信元アドレスからは推測できません。
We therefore assume in this document that if the procedures of Section 9.1.1 of [RFC6513] are to be applied to packets traveling through IR P-tunnels, those procedures will be based on the P-tunnel label, even if the IR P-tunnel is using IP unicast tunnels.
したがって、このドキュメントでは、[RFC6513]のセクション9.1.1の手順をIR Pトンネルを通過するパケットに適用する場合、それらの手順はIR Pトンネルに基づいていても、Pトンネルラベルに基づいていると想定しますトンネルはIPユニキャストトンネルを使用しています。
This means that if an egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, duplicate prevention on that IR P-tunnel requires the use of either Single Forwarder Selection (Section 9.1.2 of [RFC6513]) or native PIM procedures (Section 9.1.3 of [RFC6513]).
つまり、出力PEがセクション4.1.2の手順を使用して特定のIR Pトンネルに参加した場合、そのIR Pトンネルの重複防止には、シングルフォワーダー選択（[RFC6513]のセクション9.1.2）またはネイティブPIM手順（[RFC6513]のセクション9.1.3）。
When the Tunnel Type field of a PTA is set to "IR", the MPLS Label field is not always significant. It is significant only under the following conditions:
PTAのトンネルタイプフィールドが「IR」に設定されている場合、MPLSラベルフィールドは常に重要ではありません。これは、次の条件下でのみ重要です。
1. Either the PTA is being carried in a Leaf A-D route, or
1. PTAがリーフA-Dルートで運ばれている、または
2. the Leaf Information Required flag of the PTA is NOT set.
2. PTAのLeaf Information Requiredフラグが設定されていません。
Note that the Leaf Information Required flag of the PTA is always set when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route; thus, the MPLS Label field of the PTA is never significant when the PTA is carried by one of these route types. The MPLS Label field is significant only when the PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that does not have the Leaf Information Required bit set. In these cases, the MPLS label is the label that the originator of the route is assigning to the IR P-tunnel(s) identified by the route's NLRI. (That is, the MPLS label assigned in the PTA is what we have called the "P-tunnel label".)
PTAのLeaf Information Requiredフラグは、IR Pトンネルを指定するPTAがS-PMSI A-DルートまたはInter-AS I-PMSI A-Dルートで伝送されるときに常に設定されることに注意してください。したがって、PTAがこれらのルートタイプのいずれかで伝送される場合、PTAのMPLSラベルフィールドは決して重要ではありません。 MPLSラベルフィールドは、PTAがLeaf A-DルートまたはLeaf Information Requiredビットが設定されていないIntra-AS I-PMSI A-Dルートに表示される場合にのみ重要です。これらの場合、MPLSラベルは、ルートの発信者がルートのNLRIによって識別されるIR Pトンネルに割り当てるラベルです。 （つまり、PTAで割り当てられたMPLSラベルは、「Pトンネルラベル」と呼ばれるものです。）
In those cases where the MPLS Label field is not significant, it SHOULD be set to zero upon transmission and MUST be ignored upon reception.
MPLSラベルフィールドが重要ではない場合、送信時にゼロに設定する必要があり（SHOULD）、受信時に無視する必要があります。
As previously stated, when a Leaf A-D route is used to join an IR P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel identifier.
前述のように、リーフA-Dルートを使用してIR Pトンネルに参加する場合、リーフA-Dルートの「ルートキー」はPトンネル識別子です。
We now define the notion of the "root of an IR P-tunnel".
ここで、「IR Pトンネルのルート」の概念を定義します。
o If the identifier of an IR P-tunnel is of the form of an S-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI.
o IR Pトンネルの識別子がS-PMSI NLRIの形式である場合、IR Pトンネルの「ルート」は、そのNLRIの発信元ルーターのIPアドレスフィールドで識別されるルーターです。
o If the identifier of an IR P-tunnel is of the form specified in Section 6.2.2 of [RFC7524] ("Leaf A-D Route for Global Table Multicast"), the "root" of the IR P-tunnel is the router identified in the Ingress PE's IP Address field of that NLRI.
o IR Pトンネルの識別子が[RFC7524]のセクション6.2.2（「グローバルテーブルマルチキャストのリーフADルート」）で指定された形式である場合、IR Pトンネルの「ルート」は、そのNLRIの入力PEのIPアドレスフィールド。
o If the identifier of an IR P-tunnel is of the form of an Intra-AS I-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI.
o IR Pトンネルの識別子がIntra-AS I-PMSI NLRIの形式である場合、IR Pトンネルの「ルート」は、そのNLRIの発信元ルーターのIPアドレスフィールドで識別されるルーターです。
o If the identifier of an IR P-tunnel is of the form of an Inter-AS I-PMSI NLRI, the "root" of the IR P-tunnel is same as the identifier of the IR P-tunnel, i.e., the combination of a Route Distinguisher (RD) and an AS.
o IR Pトンネルの識別子がInter-AS I-PMSI NLRIの形式である場合、IR Pトンネルの「ルート」はIR Pトンネルの識別子と同じです。つまり、 Route Distinguisher（RD）とAS。
Note that if an IR P-tunnel is segmented, the root of the IR P-tunnel, by this definition, is actually the root of the entire P-tunnel, not the root of the local segment. In this case, there may be segments upstream that are not IR P-tunnels themselves. However, the egress PE is aware only of the final segment of the P-tunnel, and hence considers the P-tunnel to be an IR P-tunnel.
IR Pトンネルがセグメント化されている場合、この定義では、IR Pトンネルのルートは、実際にはローカルセグメントのルートではなく、Pトンネル全体のルートです。この場合、IR Pトンネル自体ではない上流のセグメントが存在する可能性があります。ただし、出力PEはPトンネルの最終セグメントのみを認識しているため、PトンネルをIR Pトンネルと見なします。
In order to apply the procedures of Section 9.1.1 of RFC 6513 ("Discarding Packets from Wrong PE"), the following condition MUST be met by the MPLS label allocation policy:
RFC 6513のセクション9.1.1の手順（「間違ったPEからのパケットの破棄」）を適用するには、MPLSラベル割り当てポリシーが次の条件を満たす必要があります。
Suppose an egress PE originates two Leaf A-D routes, each with a different route key in its NLRI, and each with a PTA specifying a Tunnel Type field of "IR". Thus, each of the Leaf A-D routes identifies a different IR P-tunnel. Suppose further that each of those IR P-tunnels has a different root. Then, the egress PE MUST NOT specify the same MPLS label in both PMSI Tunnel attributes.
出力PEが2つのLeaf A-Dルートを発信し、それぞれがそのNLRIで異なるルートキーを持ち、それぞれが「IR」のトンネルタイプフィールドを指定するPTAを持つとします。したがって、リーフA〜Dの各ルートは、異なるIR Pトンネルを識別します。さらに、これらのIR Pトンネルのそれぞれに異なるルートがあるとします。次に、出力PEは、両方のPMSIトンネル属性で同じMPLSラベルを指定してはなりません（MUST NOT）。
That is, to apply the duplicate prevention procedures (in "Discarding Packets from Wrong PE", Section 9.1.1 of [RFC6513]), the same MPLS label MUST NOT be assigned to two IR P-tunnels that have different roots.
つまり、重複防止手順（[間違ったPEからのパケットの破棄]の[RFC6513]のセクション9.1.1）を適用するには、同じルートが異なる2つのIR Pトンネルに同じMPLSラベルを割り当ててはなりません（MUST NOT）。
If segmented P-tunnels are in use, the above rule is necessary but not sufficient to prevent a PE from forwarding duplicate data to the CEs. For various reasons, a given egress PE or egress ABR or egress ASBR may decide to change its parent node, on a given segmented P-tunnel, from one router to another. It does this by changing the RT of the Leaf A-D route that it originated in order to join that P-tunnel. Once the RT is changed, there may be a period of time during which the old parent node and the new parent node are both sending data of the same multicast flow. To ensure that the egress node not forward duplicate data, whenever the egress node changes the RT that it attaches to a Leaf A-D route, it MUST also change the "MPLS Label" specified in the Leaf A-D route's PTA. This allows the egress router to distinguish between packets arriving on a given P-tunnel from the old parent and packets arriving on that same P-tunnel from the new parent. At any given time, a router MUST consider itself to have only a single parent node on a given P-tunnel and MUST discard traffic that arrives on that P-tunnel from a different parent node.
セグメント化されたPトンネルが使用されている場合、上記のルールは必要ですが、PEが重複データをCEに転送するのを防ぐには十分ではありません。さまざまな理由により、特定の出力PEまたは出力ABRまたは出力ASBRは、特定のセグメント化されたPトンネル上の親ノードを、あるルーターから別のルーターに変更することを決定する場合があります。これは、そのPトンネルに参加するために、元のリーフA-DルートのRTを変更することによって行われます。 RTが変更されると、古い親ノードと新しい親ノードの両方が同じマルチキャストフローのデータを送信している期間が存在する可能性があります。出力ノードが重複データを転送しないようにするには、出力ノードがリーフA-DルートにアタッチするRTを変更するたびに、リーフA-DルートのPTAで指定された「MPLSラベル」も変更する必要があります。これにより、出力ルーターは、特定のPトンネルに到着するパケットを古い親から受信し、同じPトンネルに到着するパケットを新しい親から区別できます。常に、ルーターは、それ自体が特定のPトンネル上に単一の親ノードのみを持っていると見なし、別の親ノードからそのPトンネルに到着するトラフィックを破棄する必要があります。
If extranet functionality [RFC7900] is not implemented in a particular egress PE, or if an egress PE is provisioned with the knowledge that extranet functionality is not needed, the PE may adopt the policy of assigning a label that is unique for the ordered triple <root, parent node, egress VRF>. This will enable the egress PE to apply the duplicate prevention procedures discussed above and to determine the VRF to which an arriving packet must be directed.
エクストラネット機能[RFC7900]が特定の出力PEに実装されていない場合、またはエクストラネット機能が不要であるという知識を備えた出力PEがプロビジョニングされている場合、PEは順序付けされたトリプルに固有のラベルを割り当てるポリシーを採用できます<ルート、親ノード、出力VRF>。これにより、出力PEは上記で説明した重複防止手順を適用し、到着するパケットの送信先となるVRFを決定できます。
However, this policy is not sufficient to support the "Do Not Deliver Packets from the Wrong P-tunnel" procedures that are specified in Section 2.3.1 of [RFC7900]. To support those procedures, the labels specified in the PTA of Leaf A-D routes originated by a given egress PE MUST be unique for the ordered triple <root, root RD, parent node>, where the "root RD" is taken from the RD field of the IR P-tunnel identifier. (All forms of IR P-tunnel identifier contain an embedded RD field.) This policy is also sufficient for supporting non-extranet cases, but, in some cases, may result in the use of more labels than the policy of the preceding paragraph.
ただし、このポリシーは、[RFC7900]のセクション2.3.1で指定されている「間違ったPトンネルからのパケットを配信しない」手順をサポートするには不十分です。これらの手順をサポートするには、特定の出力PEから発信されたリーフADルートのPTAで指定されたラベルが、順序付けされたトリプル<ルート、ルートRD、親ノード>で一意である必要があります。ここで、「ルートRD」はRDフィールドから取得されますIR Pトンネル識別子の。 （すべての形式のIR Pトンネル識別子には、埋め込みRDフィールドが含まれています。）このポリシーは、エクストラネット以外のケースをサポートするのにも十分ですが、場合によっては、前の段落のポリシーより多くのラベルを使用することがあります。
When a P-tunnel is segmented, there will be "intermediate nodes", i.e., nodes that have a parent and also have children on the P-tunnel. Each intermediate node is a leaf node of an "upstream segment" and a root node of one or more "downstream segments". The intermediate node needs to set up its forwarding state so that data it receives on the upstream segment gets transmitted on the proper downstream segments.
Pトンネルがセグメント化されると、「中間ノード」、つまりPトンネル上に親を持ち、子も持つノードがあります。各中間ノードは、「上流セグメント」の葉ノードと1つ以上の「下流セグメント」のルートノードです。中間ノードは、アップストリームセグメントで受信したデータが適切なダウンストリームセグメントで送信されるように、転送状態を設定する必要があります。
If the upstream segment is instantiated by IR, the intermediate node will need to originate a Leaf A-D route to join that segment, and will need to allocate a downstream-assigned MPLS label to advertise in the MPLS Label field of the Leaf A-D route's PTA. Section 7.1 specifies constraints on the label allocation policy for egress PEs; this section specifies constraints on the label allocation policy for intermediate nodes.
アップストリームセグメントがIRによってインスタンス化される場合、中間ノードはそのセグメントに参加するためにリーフA-Dルートを開始する必要があり、ダウンストリーム割り当てMPLSラベルを割り当てて、リーフA-DルートのPTAのMPLSラベルフィールドでアドバタイズする必要があります。セクション7.1では、出力PEのラベル割り当てポリシーに対する制約を指定しています。このセクションでは、中間ノードのラベル割り当てポリシーの制約を指定します。
Suppose intermediate node N originates two Leaf A-D routes, one whose route key is K1, and one whose route key is K2, where K1 != K2. The respective PTAs of these Leaf A-D routes MUST specify distinct non-zero MPLS labels, UNLESS the following conditions all hold:
中間ノードNが2つのリーフA-Dルートを発信するとします。1つはルートキーがK1で、もう1つはルートキーがK2です。ここで、K1！= K2です。これらのリーフA-DルートのそれぞれのPTAは、次の条件がすべて成立する場合を除き、明確な非ゼロMPLSラベルを指定する必要があります。
1. N's parent node for P-tunnel K1 is the same as N's parent node for P-tunnel K2.
1. PトンネルK1のNの親ノードは、PトンネルK2のNの親ノードと同じです。
2. N's forwarding state is such that any packet it receives from P-tunnel K1 is forwarded to the exact same set of downstream neighbors as any packet it receives from P-tunnel K2.
2. Nの転送状態では、PトンネルK1から受信したパケットは、PトンネルK2から受信したパケットとまったく同じ一連のダウンストリームネイバーに転送されます。
3. For each downstream neighbor D to which N sends the packets it receives from P-tunnels K1 and K2, N's forwarding state is such that it applies the exact same encapsulation to packets it forwards from either tunnel to D. (For example, if N uses MPLS to forward the packets to D, it pushes the exact same set of labels on packets from P-tunnel K1 as it pushes on packets from P-tunnel K2.)
3. NがPトンネルK1およびK2から受信したパケットを送信する各ダウンストリームネイバーDについて、Nの転送状態は、どちらかのトンネルからDに転送するパケットにまったく同じカプセル化を適用するようなものです（たとえば、NがMPLSはパケットをDに転送し、PトンネルK2からのパケットをプッシュするのとまったく同じラベルセットをPトンネルK1からのパケットにプッシュします。
Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates.
もちろん、Nはそれが発信する各リーフA-Dルートで常にゼロ以外の異なるラベルを指定してもよい（MAY）。
Note that the rules of this section apply whenever the upstream P-tunnel segment is an IR P-tunnel. These rules hold whether or not some or all of the downstream segments are other types of P-tunnels.
このセクションのルールは、アップストリームPトンネルセグメントがIR Pトンネルである場合は常に適用されることに注意してください。これらのルールは、ダウンストリームセグメントの一部またはすべてが他のタイプのPトンネルであるかどうかに関係なく保持されます。
If the P-tunnels from N to a particular downstream neighbor D are IR P-tunnels, then condition 3 above will hold with respect to D only if the following conditions all hold as well:
Nから特定のダウンストリームネイバーDへのPトンネルがIR Pトンネルである場合、上記の条件3は、次の条件がすべて成立する場合にのみ、Dに関して成立します。
o N has received and installed a Leaf A-D route from D, whose route key is K1, and which carries an IP-address-specific RT identifying N,
o NはDからリーフA-Dルートを受信してインストールしました。ルートキーはK1で、Nを識別するIPアドレス固有のRTを伝送します。
o N has received and installed a Leaf A-D route from D, whose route key is K2, and which carries an IP-address-specific RT identifying N,
o NはDからリーフA-Dルートを受信してインストールしました。そのルートキーはK2で、Nを識別するIPアドレス固有のRTを伝送します。
o Those two Leaf A-D routes specify the same MPLS label in their respective PTAs.
o これら2つのLeaf A-Dルートは、それぞれのPTAで同じMPLSラベルを指定します。
When a router joins a set of IR P-tunnels using the procedures of Section 4.1.2 of this document, the procedures of Section 9.1.1 of [RFC6513] cannot be applied, no matter what the label allocation policy is. In this case, the ingress PE is the same as the UMH, but it is not possible to assign a label uniquely to a particular ingress PE or UMH. However, the label in the MPLS Label field of the PTA MUST NOT appear in the MPLS Label field of the PTA carried by any other route originated by the same router.
このドキュメントのセクション4.1.2の手順を使用してルーターがIR Pトンネルのセットに参加する場合、[RFC6513]のセクション9.1.1の手順は、ラベル割り当てポリシーに関係なく適用できません。この場合、入力PEはUMHと同じですが、特定の入力PEまたはUMHに一意にラベルを割り当てることはできません。ただし、PTAのMPLSラベルフィールドのラベルは、同じルーターから発信された他のルートによって運ばれるPTAのMPLSラベルフィールドに表示してはなりません（MUST NOT）。
If a particular IR P-tunnel was joined via the procedures of Section 4.1.2, a router can prune itself from the P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join the P-tunnel. This is not usually done unless the router is removing itself entirely from a particular MVPN.
特定のIR Pトンネルがセクション4.1.2の手順で結合された場合、ルーターは、Pトンネルに結合するために使用したAS内I-PMSI A-Dルートを撤回することにより、Pトンネルから自身をプルーニングできます。これは、ルータが特定のMVPNから完全に削除されない限り、通常行われません。
The procedures in the remainder of this section apply when a router joined a particular IR P-tunnel by originating a Leaf A-D route (as described in Sections 4.1.1 or 4.2).
このセクションの残りの手順は、ルーターがリーフA-Dルートを開始して特定のIR Pトンネルに参加した場合に適用されます（セクション4.1.1または4.2で説明）。
If a router no longer has a need to receive any multicast data from a given IR P-tunnel, it may prune itself from the P-tunnel by withdrawing the Leaf A-D route it used to join the tunnel. This is done, e.g., if the router no longer needs any of the flows traveling over the P-tunnel, or if all the flows the router does need are being received over other P-tunnels.
ルーターが特定のIR Pトンネルからマルチキャストデータを受信する必要がなくなった場合、トンネルに参加するために使用したリーフA-Dルートを撤回することにより、Pトンネルから自身をプルーニングする可能性があります。これは、たとえば、ルータがPトンネルを通過するフローを必要としなくなった場合、またはルータが必要とするすべてのフローが他のPトンネルを介して受信された場合に実行されます。
A router that is attached to a particular IR P-tunnel via a particular parent node may determine that it needs to stay joined to that IR P-tunnel but via a different parent node. This can happen, for example, if there is a change in the Next Hop or the P2MP Segmented Next-Hop Extended Community of the S-PMSI A-D route in which that P-tunnel was advertised. In this case, the router changes the Route Target of the Leaf A-D route it used to join the IR P-tunnel, so that the Route Target now identifies the new parent node.
特定の親ノードを介して特定のIR Pトンネルに接続されているルーターは、別の親ノードを介してそのIR Pトンネルに参加したままにする必要があると判断する場合があります。これは、たとえば、そのPトンネルがアドバタイズされたS-PMSI A-DルートのネクストホップまたはP2MPセグメント化ネクストホップ拡張コミュニティに変更があった場合に発生する可能性があります。この場合、ルーターはIR Pトンネルへの参加に使用したリーフA-Dルートのルートターゲットを変更し、ルートターゲットが新しい親ノードを識別するようにします。
A parent node must notice when a child node has been pruned from a particular tree, as this will affect the parent node's multicast data state. Note that the pruning of a child node may appear to the parent node as the explicit withdrawal of a Leaf A-D route, or it may appear as a change in the Route Target of a Leaf A-D route. If the Route Target of a particular Leaf A-D route previously identified a particular parent node, but changes so that it no longer does so, the effect on the multicast state of the parent node is the same as if the Leaf A-D route had been explicitly withdrawn.
親ノードは、特定のツリーから子ノードがプルーニングされたときに通知する必要があります。これは、親ノードのマルチキャストデータの状態に影響を与えるためです。子ノードのプルーニングは、リーフA-Dルートの明示的な撤回として親ノードに表示される場合や、リーフA-Dルートのルートターゲットの変更として表示される場合があることに注意してください。特定のリーフADルートのルートターゲットが以前に特定の親ノードを識別していたが、変更されなくなった場合、親ノードのマルチキャスト状態への影響は、リーフADルートが明示的に撤回された場合と同じです。 。
These actions are detailed in [RFC6514] and [RFC7524]. Two points of clarification are made:
これらのアクションは、[RFC6514]と[RFC7524]で詳しく説明されています。次の2つの点を明確にします。
o If a router R1 receives and installs a Leaf A-D route originated by router R2, R1's multicast state is affected only if the Leaf A-D route carries an "IP-address-specific RT" (or "IPv6-address-specific RT") whose Global Administrator field identifies R1.
o ルータR1がルータR2から発信されたリーフADルートを受信してインストールした場合、R1のマルチキャスト状態は、リーフADルートが「IPアドレス固有のRT」（または「IPv6アドレス固有のRT」）を運ぶ場合にのみ影響を受けます。管理者フィールドはR1を識別します。
(This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D route's RT does not identify R1, but then changes so that it does identify R1, R1 must take the same actions it would take if the Leaf A-D route were newly received.
（これは[RFC6514]と[RFC7524]で指定されているとおりです。）リーフADルートのRTがR1を識別しないが、R1を識別するように変更された場合、R1はリーフADルートの場合と同じアクションを実行する必要があります。新しく入荷しました。
o It is possible that router R1 will receive and install a Leaf A-D route originated by router R2, where:
o ルータR1がルータR2から発信されたリーフA-Dルートを受信してインストールする可能性があります。
* the route's RT identifies R1,
* ルートのRTはR1を識別します
* the route's NLRI contains a route key whose first octet indicates that it is identifying a P-tunnel advertised in an S-PMSI A-D route,
* ルートのNLRIには、最初のオクテットがS-PMSI A-DルートでアドバタイズされたPトンネルを識別していることを示すルートキーが含まれています。
* R1 has neither originated nor installed any such S-PMSI A-D route.
* R1は、このようなS-PMSI A-Dルートを発信もインストールもしていません。
If at some later time, R1 installs the corresponding S-PMSI A-D route, and the Leaf A-D route is still installed, and the Leaf A-D route's RT still identifies R1, then R1 MUST follow the same procedures it would have followed if the S-PMSI A-D route had been installed before the Leaf A-D route was installed. Implementers must not assume that events occur in the "usual" or "expected" order.
後で、R1が対応するS-PMSI ADルートをインストールし、Leaf ADルートがまだインストールされていて、Leaf ADルートのRTがまだR1を識別している場合、R1は、S-リーフADルートがインストールされる前にPMSI ADルートがインストールされていました。実装者は、イベントが「通常の」または「予期された」順序で発生すると想定してはなりません。
Consider a child node that has joined a particular IR P-tunnel via a particular UMH. To do so, it will have originated a Leaf A-D route with an RT that identifies the UMH. Suppose the child node now determines (for whatever reason) that it needs to change its UMH for that P-tunnel. It does this by:
特定のUMHを介して特定のIR Pトンネルに参加した子ノードについて考えます。これを行うには、UMHを識別するRTを使用してリーフA-Dルートを作成します。子ノードが（何らかの理由で）そのPトンネルのUMHを変更する必要があると判断したとします。これは次のように行われます。
o modifying the RT of the Leaf A-D route, so that the RT now identifies the new parent rather than the old one, and by
o リーフA-DルートのARTを変更して、RIGHTが古い親ではなく新しい親を識別するようにします。
o modifying the PTA of the Leaf A-D route, changing the MPLS Label field as discussed in Section 7.
o リーフA-DルートのPTAを変更し、セクション7で説明したようにMPLSラベルフィールドを変更します。
Note that, in accordance with the procedures of [RFC6514] and of Section 4 of this document, the NLRI of the Leaf A-D route is not modified; only the RT and the PTA are changed.
[RFC6514]およびこのドキュメントのセクション4の手順に従って、リーフA-DルートのNLRIは変更されないことに注意してください。 RTとPTAのみが変更されます。
It is desirable for such a "switch of UMH" to be done using a "make before break" technique, so that the old UMH does not stop transmitting packets of the given P-tunnel to the child until the new UMH has a chance to start transmitting packets of the given P-tunnel to the child. However, the control-plane operation (i.e., modifying the RT and PTA of the Leaf A-D route) does not permit the child node to first join the IR P-tunnel via the new UMH, and then later prune itself from the old UMH. Rather, a single control-plane operation has both effects.
このような「UMHの切り替え」は、「make before break」手法を使用して行うことが望ましいため、古いUMHは、指定されたPトンネルのパケットの子への送信を、新しいUMHが指定されたPトンネルのパケットの子への送信を開始します。ただし、コントロールプレーン操作（つまり、リーフA-DルートのRTおよびPTAを変更する）では、子ノードが最初に新しいUMHを介してIR Pトンネルに参加し、その後、古いUMHからそれ自体をプルーニングすることはできません。むしろ、単一のコントロールプレーン操作には両方の効果があります。
Therefore, the old UMH MUST continue transmitting to the child node for a period of time after it sees the child's Leaf A-D route being withdrawn (or its RT changing to identify a different UMH). This timer (the "parent-continues" timer) SHOULD have a default value of 60 seconds and SHOULD be configurable.
したがって、古いUMHは、子のリーフA-Dルートが撤回されている（または別のUMHを識別するためにそのRTが変化している）ことを確認した後、しばらくの間子ノードに送信し続ける必要があります。このタイマー（「親継続」タイマー）のデフォルト値は60秒であり、構成可能である必要があります（SHOULD）。
By the procedures of Section 7, the child node will have advertised a different label for the IR P-tunnel to the new UMH than it had advertised to the old UMH. This allows it to distinguish the packets of that IR P-tunnel transmitted by the new UMH from packets of that IR P-tunnel transmitted by the old UMH. At any given time, the child node will accept packets of that IR P-tunnel from only one parent node and will discard packets of that IR P-tunnel that are received from the other. To achieve "make before break" functionality, the child node needs to continue to accept packets from the old UMH for a period of time. After this period, it will discard any packets from the given IR P-tunnel that it receives from the old UMH and will only accept such packets from the new UMH.
セクション7の手順により、子ノードは、IR Pトンネルの異なるラベルを古いUMHにアドバタイズしたものとは異なる新しいUMHにアドバタイズします。これにより、新しいUMHによって送信されたそのIR Pトンネルのパケットを、古いUMHによって送信されたそのIR Pトンネルのパケットと区別することができます。常に、子ノードは1つの親ノードからのみそのIR Pトンネルのパケットを受け入れ、他から受信したそのIR Pトンネルのパケットを破棄します。 「make before break」機能を実現するには、子ノードが一定期間、古いUMHからのパケットを受け入れ続ける必要があります。この期間が経過すると、古いUMHから受信した特定のIR Pトンネルからのパケットはすべて破棄され、新しいUMHからのパケットのみが受け入れられます。
Once the child node modifies the RT of its Leaf A-D route, it MUST run a timer (the "switch-parents-delay" timer). This timer SHOULD default to 30 seconds and SHOULD be configurable. The child node MUST continue to accept packets of the given IR P-tunnel from the old UMH until the timer expires. However, once the child node receives a packet of the given IR P-tunnel from the new UMH, it MAY consider the "switch-parents-delay" timer to have expired.
子ノードがリーフA-DルートのRTを変更したら、タイマー（「switch-parents-delay」タイマー）を実行する必要があります。このタイマーはデフォルトで30秒である必要があり（SHOULD）、構成可能である必要があります（SHOULD）。子ノードは、タイマーが期限切れになるまで、古いUMHから所定のIR Pトンネルのパケットを受け入れ続ける必要があります。ただし、子ノードが新しいUMHから特定のIR Pトンネルのパケットを受信すると、「switch-parents-delay」タイマーが満了したと見なす場合があります。
The "parent-continues" timer MUST be longer than the "switch-parents-delay" timer. Note that both timers are specific to a given IR P-tunnel.
「parent-continues」タイマーは、「switch-parents-delay」タイマーよりも長くなければなりません。両方のタイマーは、特定のIR Pトンネルに固有であることに注意してください。
No security considerations are raised by this document beyond those already discussed in [RFC6513] and [RFC6514].
このドキュメントでは、[RFC6513]および[RFC6514]ですでに説明されているものを超えて、セキュリティに関する考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、DOI 10.17487 / RFC6513、February 2012、<http：//www.rfc-editor .org / info / rfc6513>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< http://www.rfc-editor.org/info/rfc6514>。
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <http://www.rfc-editor.org/info/rfc6515>.
[RFC6515] Aggarwal、R。およびE. Rosen、「マルチキャストVPNのBGPアップデートにおけるIPv4およびIPv6インフラストラクチャアドレス」、RFC 6515、DOI 10.17487 / RFC6515、2012年2月、<http://www.rfc-editor.org/ info / rfc6515>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Ed。、Minei、I.、Ed。、Kompella、K.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、RFC 6388、DOI 10.17487 / RFC6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャストVPNオートディスカバリルートのワイルドカード」、RFC 6625、DOI 10.17487 / RFC6625、2012年5月、<http://www.rfc-editor.org/info/rfc6625>。
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <http://www.rfc-editor.org/info/rfc7524>.
[RFC7524] Rekhter、Y.、Rosen、E.、Aggarwal、R.、Morin、T.、Grosclaude、I.、Leymann、N。、およびS. Saad、「エリア間ポイントツーマルチポイント（P2MP）セグメント化ラベルスイッチドパス（LSP）」、RFC 7524、DOI 10.17487 / RFC7524、2015年5月、<http://www.rfc-editor.org/info/rfc7524>。
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <http://www.rfc-editor.org/info/rfc7582>.
[RFC7582] Rosen、E.、Wijnands、IJ。、Cai、Y。、およびA. Boers、「Multicast Virtual Private Network（MVPN）：Using Bidirectional P-Tunnels」、RFC 7582、DOI 10.17487 / RFC7582、2015年7月、 <http://www.rfc-editor.org/info/rfc7582>。
[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., and D. Pacella, "Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures", RFC 7716, DOI 10.17487/RFC7716, December 2015, <http://www.rfc-editor.org/info/rfc7716>.
[RFC7716] Zhang、J.、Giuliano、L.、Rosen、E.、Ed。、Subramanian、K.、and D. Pacella、 "Global Table Multicast with BGP Multicast VPN（BGP-MVPN）Procedures"、RFC 7716、 DOI 10.17487 / RFC7716、2015年12月、<http://www.rfc-editor.org/info/rfc7716>。
[RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication", RFC 7740, DOI 10.17487/RFC7740, January 2016, <http://www.rfc-editor.org/info/rfc7740>.
[RFC7740] Zhang、Z.、Rekhter、Y。、およびA. Dolganow、「マルチポイントツーマルチポイント（MP2MP）プロバイダートンネルの部分レプリケーションをシミュレートするイングレスレプリケーション」、RFC 7740、DOI 10.17487 / RFC7740、2016年1月、< http://www.rfc-editor.org/info/rfc7740>。
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, <http://www.rfc-editor.org/info/rfc7900>.
[RFC7900] Rekhter、Y.、Ed。、Rosen、E.、Ed。、Aggarwal、R.、Cai、Y。、およびT. Morin、「BGP / IP MPLS VPNでのエクストラネットマルチキャスト」、RFC 7900、DOI 10.17487 / RFC7900、2016年6月、<http://www.rfc-editor.org/info/rfc7900>。
Acknowledgments
謝辞
The authors wish to thank Yakov Rekhter for his contributions to this work. We also wish to thank Huajin Jeng and Samir Saad for their contributions, and to thank Thomas Morin for pointing out (both before and after the document was written) some of the issues that needed further elaboration. We also thank Lucy Yong for her review and comments.
著者は、この作業への貢献に対してYakov Rekhterに感謝します。また、Huajin JengとSamir Saadの貢献に感謝し、Thomas Morinに（ドキュメントの作成前と作成後の両方で）さらに詳しい説明が必要な問題を指摘してくれたことに感謝します。彼女のレビューとコメントをしてくれたLucy Yongにも感謝します。
Section 7.1 discusses the importance of having an MPLS label allocation policy that, when ingress replication is used, allows an egress PE to infer the identity of a received packet's ingress PE. This issue was first raised in earlier work by Xu Xiaohu.
セクション7.1では、MPLSラベル割り当てポリシーを使用することの重要性について説明します。これにより、入力レプリケーションが使用されたときに、出力PEが受信パケットの入力PEのIDを推測できるようになります。この問題は、Xu Xiaohuによる以前の研究で最初に取り上げられました。
Authors' Addresses
著者のアドレス
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
エリックC.ローゼン（編集者）ジュニパーネットワークス社10テクノロジーパークドライブウェストフォード、マサチューセッツ01886アメリカ合衆国
Email: erosen@juniper.net
Karthik Subramanian Sproute Networks
Karthik Subramanian Sproute Networks
Email: karthik@sproute.com
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Zhaohui Zhang Juniper Networks、Inc. 10 Technology Park Drive Westford、Massachusetts 01886アメリカ合衆国
Email: zzhang@juniper.net