[要約] RFC 7438は、Multipoint LDP（mLDP）のインバンドシグナリングにおけるワイルドカードの使用に関する規格です。このRFCの目的は、mLDPにおけるワイルドカードの使用を可能にし、ネットワークのスケーラビリティと柔軟性を向上させることです。
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7438 Cisco Systems, Inc.
Updates: 6826, 7246 E. Rosen
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 A. Gulko
Thomson Reuters
U. Joorde
Deutsche Telekom
J. Tantsura
Ericsson
January 2015
Multipoint LDP (mLDP) In-Band Signaling with Wildcards
ワイルドカードを使用したマルチポイントLDP（mLDP）インバンドシグナリング
Abstract
概要
There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP-LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.
IPマルチキャストツリーがMPLSドメインを通過するシナリオがあります。これらのシナリオでは、MPLSドメインに入るときにIPマルチキャストツリーを「シームレスに」MPLSマルチポイントラベルスイッチドパス（MP-LSP）に変換し、終了するときにIPマルチキャストツリーに戻すことが望ましい場合があります。 MPLSドメイン。以前のドキュメントでは、特定の種類のIPマルチキャストツリー（送信元固有のマルチキャストツリーまたは双方向マルチキャストツリー）をMPLSマルチポイントラベルスイッチドパス（MP-LSP）に接続できるようにする手順を指定しています。ただし、以前のドキュメントでは、IP Any-Source MulticastツリーをMP-LSPに接続する手順は指定されておらず、複数のIPマルチキャストツリーを単一のMP-LSPに集約する手順も指定されていません。このドキュメントでは、これらの機能をサポートする手順について説明します。これは、MP-LSPのセットアップ時に、IPマルチキャストツリーのセットまたは共有IPマルチキャストツリーをそのMP-LSPに接続するように指定できるようにする「ワイルドカード」エンコーディングを定義することによって行われます。非双方向IP Any-Sourceマルチキャストツリーのサポートには、このドキュメントで説明されている特定の適用性の制限が適用されます。このドキュメントは、RFC 6826および7246を更新します。
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/rfc7438.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7438で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 7
3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7
3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 8
3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8
3.4. Applicability Restrictions with Regard to ASM . . . . . . 9
4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9
4.1. PIM Shared Tree Forwarding . . . . . . . . . . . . . . . 9
4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 11
4.3. Selective Source Mapping . . . . . . . . . . . . . . . . 11
5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11
6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 13
7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 13
8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
[RFC6826] and [RFC7246] specify procedures for mLDP (Multipoint LDP) that allow an IP multicast tree (either a Source-Specific Multicast tree or a Bidirectional Multicast tree) to be attached "seamlessly" to an MPLS Multipoint Label Switched Path (MP-LSP). This can be useful, for example, when there is multicast data that originates in a domain that supports IP multicast, which then has to be forwarded across a domain that supports MPLS multicast and then has to forwarded across another domain that supports IP multicast. By attaching an IP multicast tree to an MP-LSP, data that is traveling along the IP multicast tree can be moved seamlessly to the MP-LSP when it enters the MPLS multicast domain. The data then travels along the MP-LSP through the MPLS domain. When the data reaches the boundary of the MPLS domain, it can be moved seamlessly to an IP multicast tree. This ability to attach IP multicast trees to MPLS MP-LSPs can be useful in either VPN context or global context.
[RFC6826]および[RFC7246]は、IPマルチキャストツリー（送信元固有のマルチキャストツリーまたは双方向マルチキャストツリー）をMPLSマルチポイントラベルスイッチドパス（MP -LSP）。これは、たとえば、IPマルチキャストをサポートするドメインで発生したマルチキャストデータがあり、MPLSマルチキャストをサポートするドメイン全体に転送し、次にIPマルチキャストをサポートする別のドメイン全体に転送する必要がある場合に役立ちます。 IPマルチキャストツリーをMP-LSPに接続することにより、IPマルチキャストツリーに沿って移動するデータを、MPLSマルチキャストドメインに入るときにシームレスにMP-LSPに移動できます。その後、データはMPLSドメインに沿ってMP-LSPに沿って移動します。データがMPLSドメインの境界に到達すると、シームレスにIPマルチキャストツリーに移動できます。 IPマルチキャストツリーをMPLS MP-LSPに接続するこの機能は、VPNコンテキストまたはグローバルコンテキストのいずれかで役立ちます。
In mLDP, every MP-LSP is identified by the combination of a "root node" (or "Ingress Label Switching Router (LSR)") and an "Opaque Value" that, in the context of the root node, uniquely identifies the MP-LSP. These are encoded into an mLDP "Forwarding Equivalence Class (FEC) Element". To set up an MP-LSP, the Egress LSRs originate mLDP control messages containing the FEC element. A given FEC Element value identifies a single MP-LSP and is passed upstream from the Egress LSRs, through the intermediate LSRs, to the Ingress LSR.
mLDPでは、すべてのMP-LSPは、「ルートノード」（または「入力ラベルスイッチングルーター（LSR）」）と「ルート値」のコンテキストでMPを一意に識別する「不透明値」の組み合わせによって識別されます。 -LSP。これらは、mLDP「Forwarding Equivalence Class（FEC）Element」にエンコードされます。 MP-LSPを設定するために、出力LSRはFEC要素を含むmLDP制御メッセージを発信します。特定のFEC Element値は単一のMP-LSPを識別し、出力LSRから中間LSRを介して上りLSRに渡されます。
In IP multicast, a multicast tree is identified by the combination of an IP source address ("S") and an IP group address ("G"), usually written as "(S,G)". A tree carrying traffic of multiple sources is identified by its group address, and the identifier is written as "(*,G)".
IPマルチキャストでは、マルチキャストツリーは、IP送信元アドレス（ "S"）とIPグループアドレス（ "G"）の組み合わせによって識別され、通常は（S、G）と表記されます。複数の送信元のトラフィックを運ぶツリーは、そのグループアドレスで識別され、識別子は「（*、G）」と記述されます。
When an MP-LSP is being set up, the procedures of [RFC6826] and [RFC7246], known as "mLDP in-band signaling", allow the Egress LSRs of the MP-LSP to encode the identifier of an IP multicast tree in the "Opaque Value" field of the mLDP FEC Element that identifies the MP-LSP. Only the Egress and Ingress LSRs are aware that the mLDP FEC Elements contain encodings of the IP multicast tree identifier; intermediate nodes along the MP-LSP do not take any account of the internal structure of the FEC Element's Opaque Value, and the internal structure of the Opaque Value does not affect the operation of mLDP. By using mLDP in-band signaling, the Egress LSRs of an MP-LSP inform the Ingress LSR that they expect traffic of the identified IP multicast tree (and only that traffic) to be carried on the MP-LSP. That is, mLDP in-band signaling not only sets up the MP-LSP, it also binds a given IP multicast tree to the MP-LSP.
MP-LSPがセットアップされている場合、「mLDPインバンドシグナリング」として知られる[RFC6826]および[RFC7246]の手順により、MP-LSPの出力LSRでIPマルチキャストツリーの識別子をエンコードできます。 MP-LSPを識別するmLDP FEC要素の「不透明な値」フィールド。出力および入力LSRのみが、mLDP FEC要素にIPマルチキャストツリー識別子のエンコーディングが含まれていることを認識しています。 MP-LSPに沿った中間ノードは、FEC要素の不透明値の内部構造を考慮せず、不透明値の内部構造はmLDPの動作に影響しません。 mLDPインバンドシグナリングを使用することにより、MP-LSPの出力LSRは、識別されたIPマルチキャストツリーのトラフィック（およびそのトラフィックのみ）がMP-LSPで伝送されることを期待することを入力LSRに通知します。つまり、mLDPインバンドシグナリングは、MP-LSPをセットアップするだけでなく、特定のIPマルチキャストツリーをMP-LSPにバインドします。
If multicast is being done in a VPN context [RFC7246], then the mLDP FEC elements also contain a "Route Distinguisher" (RD) (see [RFC7246]), as the IP multicast trees are identified not merely by "(S,G)" but by "(RD,S,G)". The procedures of this document are also applicable in this case. Of course, when an Ingress LSR processes an in-band signaling Opaque Value that contains an RD, it does so in the context of the VPN associated with that RD.
マルチキャストがVPNコンテキスト[RFC7246]で行われている場合、IPマルチキャストツリーは単に（S、Gで識別されないため、mLDP FEC要素には「ルート識別子」（RD）（[RFC7246]を参照）も含まれます。 ）」によるが、「（RD、S、G）」による。このドキュメントの手順は、この場合にも適用されます。もちろん、入力LSRがRDを含むインバンドシグナリングの不透明値を処理する場合、そのRDに関連付けられたVPNのコンテキストで処理します。
If mLDP in-band signaling is not used, then some other protocol must be used to bind an IP multicast tree to the MP-LSP; this requires additional communication mechanisms between the Ingress LSR and the Egress LSRs of the MP-LSP. The purpose of mLDP in-band signaling is to eliminate the need for these other protocols.
mLDPインバンドシグナリングを使用しない場合は、他のプロトコルを使用してIPマルチキャストツリーをMP-LSPにバインドする必要があります。これには、MP-LSPの入力LSRと出力LSRの間に追加の通信メカニズムが必要です。 mLDPインバンドシグナリングの目的は、これらの他のプロトコルの必要性を排除することです。
When following the procedures of [RFC6826] and [RFC7246] for non-bidirectional trees, the Opaque Value has an IP source address (S) and an IP group address (G) encoded into it, thus enabling it to identify a particular IP multicast (S,G) tree. Only a single IP source-specific multicast tree (i.e., a single "(S,G)") can be identified in a given FEC element. As a result, a given MP-LSP can carry data from only a single IP source-specific multicast tree (i.e., a single "(S,G) tree"). However, there are scenarios in which it would be desirable to aggregate a number of (S,G) trees on a single MP-LSP. Aggregation allows a given number of IP multicast trees to use a smaller number of MP-LSPs, thus saving state in the network.
[RFC6826]および[RFC7246]の手順に従って非双方向ツリーを作成すると、不透明値にIPソースアドレス（S）とIPグループアドレス（G）がエンコードされ、特定のIPマルチキャストを識別できるようになります。 （S、G）ツリー。特定のFECエレメントで識別できるのは、単一のIPソース固有のマルチキャストツリー（つまり、単一の「（S、G）」）だけです。その結果、特定のMP-LSPは、単一のIPソース固有のマルチキャストツリー（つまり、単一の「（S、G）ツリー」）からのみデータを伝送できます。ただし、複数の（S、G）ツリーを単一のMP-LSPに集約することが望ましいシナリオがあります。集約により、特定の数のIPマルチキャストツリーがより少ない数のMP-LSPを使用できるようになり、ネットワークの状態が保存されます。
In addition, [RFC6826] and [RFC7246] do not support the attachment of an Any-Source Multicast (ASM) shared tree to an MP-LSP, except in the case where the ASM shared tree is a bidirectional tree (i.e., a tree set up by BIDIR-PIM [RFC5015]). However, there are scenarios in which it would be desirable to attach a non-bidirectional ASM shared tree to an MP-LSP.
さらに、[RFC6826]および[RFC7246]は、ASM共有ツリーが双方向ツリー（つまり、ツリー）である場合を除いて、Any-Source Multicast（ASM）共有ツリーのMP-LSPへのアタッチをサポートしていません。 BIDIR-PIM [RFC5015]によってセットアップされます）。ただし、非双方向ASM共有ツリーをMP-LSPに接続することが望ましいシナリオがあります。
This document specifies a way to encode an mLDP "Opaque Value" in which either the "S" or the "G" or both are replaced by a "wildcard" (written as "*"). Procedures are described for using the wildcard encoding to map non-bidirectional ASM shared trees to MP-LSPs and for mapping multiple (S,G) trees (with a common value of S or a common value of G) to a single MP-LSP.
このドキュメントでは、 "S"または "G"またはその両方が "ワイルドカード"（ "*"と表記）に置き換えられたmLDP "不透明な値"をエンコードする方法を指定します。ワイルドカードエンコーディングを使用して非双方向ASM共有ツリーをMP-LSPにマッピングし、複数の（S、G）ツリーを（共通の値Sまたは共通の値Gで）単一のMP-LSPにマッピングする手順について説明します。 。
Some example scenarios where wildcard encoding is useful are
ワイルドカードエンコーディングが役立ついくつかのシナリオ例は、
o PIM shared tree forwarding with "threshold infinity";
o PIMは「しきい値無限大」でツリー転送を共有しました。
o IGMP/Multicast Listener Discovery (MLD) proxying; and
o IGMP /マルチキャストリスナー検出（MLD）プロキシ。そして
o Selective Source mapping.
o 選択的ソースマッピング。
These scenarios are discussed in Section 4. Note that this list of scenarios is not meant to be exhaustive.
これらのシナリオについては、セクション4で説明します。このシナリオのリストは、すべてを網羅しているわけではありません。
This document specifies only the mLDP procedures that are specific to the use of wildcards. mLDP in-band signaling procedures that are not specific to the use of wildcards can be found in [RFC6826] and [RFC7246]. Unless otherwise specified in this document, those procedures still apply when wildcards are used.
このドキュメントでは、ワイルドカードの使用に固有のmLDP手順のみを指定しています。ワイルドカードの使用に固有ではないmLDPインバンドシグナリング手順は、[RFC6826]および[RFC7246]にあります。このドキュメントで特に指定されていない限り、ワイルドカードが使用されている場合でもこれらの手順は適用されます。
Readers of this document are assumed to be familiar with the terminology and concepts of the documents listed as Normative References. For convenience, some of the more frequently used terms appear below.
このドキュメントの読者は、規範的な参照としてリストされているドキュメントの用語と概念に精通していることが前提となっています。便宜上、よく使用される用語の一部を以下に示します。
IGMP: Internet Group Management Protocol.
IGMP：インターネットグループ管理プロトコル。
In-band signaling: Using the opaque value of a mLDP FEC element to carry the (S,G) or (*,G) identifying a particular IP multicast tree. This document also allows (S,*) to be encoded in the opaque value; see Section 6.
インバンドシグナリング：mLDP FEC要素の不透明な値を使用して、特定のIPマルチキャストツリーを識別する（S、G）または（*、G）を伝送します。このドキュメントでは、（S、*）を不透明な値にエンコードすることもできます。セクション6を参照してください。
Ingress LSR: Root node of a MP-LSP. When mLDP in-band signaling is used, the Ingress LSR receives mLDP messages about a particular MP-LSP from downstream and emits IP multicast control messages upstream. The set of IP multicast control messages that are emitted upstream depends upon the contents of the LDP Opaque Value TLVs. The Ingress LSR also receives IP multicast data messages from upstream and sends them downstream as MPLS packets on an MP-LSP.
入力LSR：MP-LSPのルートノード。 mLDPインバンドシグナリングが使用される場合、入力LSRは特定のMP-LSPに関するmLDPメッセージをダウンストリームから受信し、IPマルチキャスト制御メッセージをアップストリームに送信します。アップストリームに送信されるIPマルチキャスト制御メッセージのセットは、LDP不透明値TLVの内容によって異なります。入力LSRは、アップストリームからIPマルチキャストデータメッセージを受信し、MP-LSP上のMPLSパケットとしてダウンストリームに送信します。
IP multicast tree: An IP multicast distribution tree identified by an IP multicast group address and optionally a source IP address, also referred to as (S,G) and (*,G).
IPマルチキャストツリー：（S、G）および（*、G）とも呼ばれる、IPマルチキャストグループアドレスおよびオプションで送信元IPアドレスによって識別されるIPマルチキャスト配信ツリー。
MLD: Multicast Listener Discovery.
MLD：マルチキャストリスナーの発見。
mLDP: Multipoint LDP.
mLDP：マルチポイントLDP。
MP-LSP: A Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP) LSP.
MP-LSP：ポイントツーマルチポイント（P2MP）またはマルチポイントツーマルチポイント（MP2MP）LSP。
PIM: Protocol Independent Multicast.
PIM：Protocol Independent Multicast。
PIM-ASM: PIM Any-Source Multicast.
PIM-ASM：PIM Any-Source Multicast。
PIM-SM: PIM Sparse Mode.
PIM-SM：PIMスパースモード。
PIM-SSM: PIM Source-Specific Multicast.
PIM-SSM：PIM Source-Specific Multicast。
RP: The PIM Rendezvous Point.
RP：PIMランデブーポイント。
Egress LSR: The Egress LSRs of an MP-LSP are LSPs that receive MPLS multicast data packets from upstream on that MP-LSP, and that forward that data downstream as IP multicast data packets. The Egress LSRs also receive IP multicast control messages from downstream and send mLDP control messages upstream. When in-band signaling is used, the Egress LSRs construct Opaque Value TLVs that contain IP source and/or group addresses based on the contents of the IP multicast control messages received from downstream.
出力LSR：MP-LSPの出力LSRは、そのMP-LSPのアップストリームからMPLSマルチキャストデータパケットを受信し、そのデータをIPマルチキャストデータパケットとしてダウンストリームに転送するLSPです。出力LSRは、ダウンストリームからIPマルチキャスト制御メッセージを受信し、mLDP制御メッセージをアップストリームに送信します。インバンドシグナリングが使用される場合、出力LSRは、ダウンストリームから受信したIPマルチキャスト制御メッセージの内容に基づいて、IP送信元および/またはグループアドレスを含む不透明値TLVを構築します。
Threshold Infinity: A PIM-SM procedure where no source-specific multicast (S,G) trees are created for multicast packets that are forwarded down the shared tree (*,G).
しきい値の無限大：共有ツリー（*、G）に転送されるマルチキャストパケットに対して、ソース固有のマルチキャスト（S、G）ツリーが作成されないPIM-SM手順。
TLV: A protocol element consisting of a type field, followed by a length field, followed by a value field. Note that the value field of a TLV may be subdivided into a number of subfields.
TLV：タイプフィールド、長さフィールド、値フィールドの順に構成されるプロトコル要素。 TLVの値フィールドは、いくつかのサブフィールドに分割できることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
[RFC6826] and [RFC7246] define the following Opaque Value TLVs: Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4 Source TLV, and Transit VPNv6 Source TLV. The value field of each such TLV is divided into a number of subfields, one of which contains an IP source address, and one of which contains an IP group address. Per those documents, these fields must contain valid IP addresses.
[RFC6826]と[RFC7246]は、次のOpaque Value TLVを定義しています：Transit IPv4 Source TLV、Transit IPv6 Source TLV、Transit VPNv4 Source TLV、およびTransit VPNv6 Source TLV。そのような各TLVの値フィールドは、いくつかのサブフィールドに分割されます。1つはIP送信元アドレスを含み、1つはIPグループアドレスを含みます。これらのドキュメントによれば、これらのフィールドには有効なIPアドレスが含まれている必要があります。
This document extends the definition of those TLVs by allowing either the IP source address field or the IP group address field (or both) to specify a "wildcard" rather than a valid IP address.
このドキュメントでは、IPソースアドレスフィールドまたはIPグループアドレスフィールド（あるいはその両方）で有効なIPアドレスではなく「ワイルドカード」を指定できるようにすることで、それらのTLVの定義を拡張しています。
A value of all zeroes in the IP source address subfield is used to represent a wildcard source address. A value of all zeroes in the IP group address subfield is used to represent the wildcard group address. Note that the lengths of these subfields are as specified in the previous documents.
IP送信元アドレスサブフィールドのすべてのゼロの値は、ワイルドカード送信元アドレスを表すために使用されます。 IPグループアドレスサブフィールドのすべてゼロの値は、ワイルドカードグループアドレスを表すために使用されます。これらのサブフィールドの長さは、前のドキュメントで指定されているとおりです。
If the IP source address subfield contains the wildcard, and the IP group address subfield contains an IP multicast group address that is NOT in the SSM address range (see Section 4.8 of [RFC4601]), then the TLV identifies a PIM-SM shared tree. Please see Section 3.4 for the applicability restrictions that apply to this case.
IPソースアドレスサブフィールドにワイルドカードが含まれ、IPグループアドレスサブフィールドにSSMアドレス範囲にないIPマルチキャストグループアドレスが含まれている場合（[RFC4601]のセクション4.8を参照）、TLVはPIM-SM共有ツリーを識別します。このケースに適用される適用制限については、セクション3.4を参照してください。
If the IP source address subfield contains the wildcard, and the IP group address subfield contains an IP multicast group address that is in the SSM address range, then the TLV identifies the collection of PIM trees with the given group address.
IPソースアドレスサブフィールドにワイルドカードが含まれ、IPグループアドレスサブフィールドにSSMアドレス範囲内のIPマルチキャストグループアドレスが含まれている場合、TLVは指定されたグループアドレスでPIMツリーのコレクションを識別します。
If the IP source address subfield contains a non-zero IP address, and the IP group address subfield contains the wildcard, the TLV identifies the collection of PIM-SSM trees that have the source address as their root.
IP送信元アドレスサブフィールドにゼロ以外のIPアドレスが含まれ、IPグループアドレスサブフィールドにワイルドカードが含まれている場合、TLVは送信元アドレスをルートとするPIM-SSMツリーのコレクションを識別します。
Procedures for the use of the wildcards are discussed in Sections 4, 5, and 6. Please note that, as always, the structure of an Opaque Value TLV does not affect the operation of mLDP. The structure is meaningful only to the IP multicast modules at the Ingress and Egress LSRs.
ワイルドカードの使用手順については、セクション4、5、および6で説明します。いつものように、不透明値TLVの構造はmLDPの動作に影響しないことに注意してください。この構造は、入力および出力LSRのIPマルチキャストモジュールに対してのみ意味があります。
Procedures for the use of a wildcard group in the following TLVs (defined in [RFC6826] or [RFC7246]) are outside the scope of the current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV, Transit VPNv4 Bidir TLV, and Transit VPNv6 Bidir TLV.
次のTLV（[RFC6826]または[RFC7246]で定義）でワイルドカードグループを使用する手順は、現在のドキュメントの範囲外です：Transit IPv4 Bidir TLV、Transit IPv6 Bidir TLV、Transit VPNv4 Bidir TLV、およびTransit VPNv6 Bidir TLV。
Procedures for the use of both a wildcard source and a wildcard group in the same TLV are outside the scope of the current document.
同じTLVでワイルドカードソースとワイルドカードグループの両方を使用する手順は、現在のドキュメントの範囲外です。
Note that the Bidir TLVs do not have a source address subfield, and hence the notion of a wildcard source is not applicable to them.
Bidir TLVには送信元アドレスサブフィールドがないため、ワイルドカード送信元の概念はそれらに適用されないことに注意してください。
The procedures of this document do not change the behavior described in [RFC6826] and [RFC7246].
このドキュメントの手順は、[RFC6826]と[RFC7246]で説明されている動作を変更しません。
A correctly operating Egress LSR that supports [RFC6826] and/or [RFC7246], but that does not support this document, will never generate mLDP FEC Element Opaque values that contain source or group wildcards.
[RFC6826]や[RFC7246]をサポートしているが、このドキュメントをサポートしていない正常に動作する出力LSRは、ソースまたはグループのワイルドカードを含むmLDP FEC Element Opaque値を生成しません。
Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress LSR that receives mLDP FEC Element Opaque values that contain zeroes in the source address or group address subfields. However, if an Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support this document, then it has no choice but to treat any such received FEC elements as invalid; the procedures specified in [RFC6826] and [RFC7246] do not work when the Opaque values contain zeroes in the source address or group address subfields.
[RFC6826]も[RFC7246]も、送信元アドレスまたはグループアドレスサブフィールドにゼロを含むmLDP FEC Element Opaque値を受信するIngress LSRの動作を指定していません。ただし、Ingress LSRが[RFC6826]や[RFC7246]をサポートしているが、このドキュメントをサポートしていない場合は、受信したFEC要素を無効として扱うしかありません。 [RFC6826]と[RFC7246]で指定された手順は、Opaque値のソースアドレスまたはグループアドレスのサブフィールドにゼロが含まれている場合は機能しません。
The procedures of this document thus presuppose that if an Egress LSR uses wildcard encodings when setting up an MP-LSP, then the Ingress LSR (i.e., the root of the multipoint LSP) supports the procedures of this document. An Egress LSR MUST NOT use wildcard encodings when setting up a particular multipoint LSP unless it is known a priori that the Ingress LSR supports the procedures of this document. How this is known is outside the scope of this document.
したがって、このドキュメントの手順では、MP-LSPの設定時に出力LSRがワイルドカードエンコーディングを使用する場合、入力LSR（つまり、マルチポイントLSPのルート）がこのドキュメントの手順をサポートすることを前提としています。入力LSRがこのドキュメントの手順をサポートすることがアプリオリにわかっている場合を除き、特定のマルチポイントLSPを設定するときに、出力LSRはワイルドカードエンコーディングを使用してはなりません（MUST NOT）。これがどのように知られているかは、このドキュメントの範囲外です。
In general, support for non-bidirectional PIM-ASM trees requires (a) a procedure for determining the set of sources for a given ASM tree ("source discovery"), and (b) a procedure for pruning a particular source off a shared tree ("source pruning"). No such procedures are specified in this document. Therefore, the combination of a wildcard source with an ASM group address MUST NOT be used unless it is known a priori that neither source discovery nor source pruning are needed. How this is known is outside the scope of this document. Section 4 describes some use cases in which source discovery and source pruning are not needed.
一般に、非双方向PIM-ASMツリーのサポートには、（a）特定のASMツリーのソースのセットを決定する手順（「ソースディスカバリ」）、および（b）共有から特定のソースをプルーニングする手順が必要です。ツリー（「ソースプルーニング」）。このドキュメントでは、そのような手順は指定されていません。したがって、ワイルドカードソースとASMグループアドレスの組み合わせは、ソースの検出もソースのプルーニングも不要であることが事前にわかっている場合を除いて、使用してはなりません。これがどのように知られているかは、このドキュメントの範囲外です。セクション4では、ソースの検出とソースのプルーニングが不要ないくつかの使用例について説明します。
There are, of course, use cases where source discovery and/or source pruning is needed. These can be handled with procedures such as those specified in [RFC6513], [RFC6514], and [GTM]. Use of mLDP in-band signaling is NOT RECOMMENDED for those cases.
もちろん、ソースの検出やソースのプルーニングが必要なユースケースもあります。これらは、[RFC6513]、[RFC6514]、および[GTM]で指定されているような手順で処理できます。これらのケースでは、mLDPインバンドシグナリングの使用は推奨されません。
This section discusses a number of wildcard use cases. The set of use cases here is not meant to be exhaustive. In each of these use cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain wildcards in the IP source address or IP group address subfields.
このセクションでは、いくつかのワイルドカードの使用例について説明します。ここでの一連の使用例は、すべてを網羅しているわけではありません。これらの使用例のそれぞれで、出力LSRは、IP送信元アドレスまたはIPグループアドレスサブフィールドにワイルドカードを含むmLDP不透明値TLVを構築します。
PIM [RFC4601] has the concept of a "shared tree", identified as (*,G). This concept is only applicable when G is an IP multicast group address that is not in the SSM address range (i.e., is an ASM group address). Every ASM group is associated with a Rendezvous Point (RP), and the (*,G) tree is built towards the RP (i.e., its root is the RP). The RP for group G is responsible for forwarding packets down the (*,G) tree. The packets forwarded down the (*,G) tree may be from any multicast source, as long as they have an IP destination address of G.
PIM [RFC4601]には、（*、G）として識別される「共有ツリー」の概念があります。この概念は、GがSSMアドレス範囲にないIPマルチキャストグループアドレスである（つまり、ASMグループアドレスである）場合にのみ適用されます。すべてのASMグループはランデブーポイント（RP）に関連付けられ、（*、G）ツリーはRPに向けて構築されます（つまり、ルートはRPです）。グループGのRPは、（*、G）ツリーの下にパケットを転送します。 （*、G）ツリーの下に転送されるパケットは、GのIP宛先アドレスを持っている限り、どのマルチキャストソースからのものでもかまいません。
The RP learns about all the multicast sources for a given group and then joins a source-specific tree for each such source. That is, when the RP for G learns that S has multicast data to send to G, the RP joins the (S,G) tree. When the RP receives multicast data from S that is destined to G, the RP forwards the data down the (*,G) tree. There are several different ways that the RP may learn about the sources for a given group. The RP may learn of sources via PIM Register messages [RFC4601], via Multicast Source Discovery Protocol (MSDP) [RFC3618], or by observing packets from a source that is directly connected to the RP.
RPは、特定のグループのすべてのマルチキャストソースについて学習し、そのようなソースごとにソース固有のツリーに参加します。つまり、SがGに送信するマルチキャストデータを持っていることをGのRPが学習すると、RPは（S、G）ツリーに参加します。 RPがSからG宛てのマルチキャストデータを受信すると、RPはそのデータを（*、G）ツリーに転送します。 RPが特定のグループのソースについて学習する方法はいくつかあります。 RPは、PIM Registerメッセージ[RFC4601]、マルチキャストソースディスカバリプロトコル（MSDP）[RFC3618]、またはRPに直接接続されているソースからのパケットを監視することで、ソースを知ることができます。
In PIM, a PIM router that has receivers for a particular ASM multicast group G (known as a "last hop" router for G) will first join the (*,G) tree. As it receives multicast traffic on the (*,G) tree, it learns (by examining the IP headers of the multicast data packets) the sources that are transmitting to G. Typically, when a last hop router for group G learns that source S is transmitting to G, the last hop router joins the (S,G) tree and "prunes" S off the (*,G) tree. This allows each last hop router to receive the multicast data along the shortest path from the source to the last hop router. (Full details of this behavior can be found in [RFC4601].)
PIMでは、特定のASMマルチキャストグループG（Gの「ラストホップ」ルーターと呼ばれる）のレシーバーを持つPIMルーターが最初に（*、G）ツリーに参加します。 （*、G）ツリーでマルチキャストトラフィックを受信すると、Gに送信しているソースを（マルチキャストデータパケットのIPヘッダーを調べて）学習します。通常、グループGのラストホップルーターがソースSを学習すると、がGに送信しているとき、最後のホップのルーターは（S、G）ツリーに参加し、（*、G）ツリーからSを「プルーニング」します。これにより、各ラストホップルーターは、ソースからラストホップルーターへの最短パスに沿ってマルチキャストデータを受信できます。 （この動作の詳細は[RFC4601]にあります。）
In some cases, however, a last hop router for group G may decide not to join the source trees, but rather to keep receiving all the traffic for G from the (*,G) tree. In this case, we say that the last hop router has "threshold infinity" for group G. This is optional behavior documented in [RFC4601]. "Threshold infinity" is often used in deployments where the RP is between the multicast sources and the multicast receivers for group G, i.e., in deployments where it is known that the shortest path from any source to any receiver of the group goes through the RP. In these deployments, there is no advantage for a last hop router to join a source tree since the data is already traveling along the shortest path. The only effect of executing the complicated procedures for joining a source tree and pruning the source off the shared tree would be to increase the amount of multicast routing state that has to be maintained in the network.
ただし、場合によっては、グループGのラストホップルーターがソースツリーに参加せず、（*、G）ツリーからGのすべてのトラフィックを受信し続けることを決定することがあります。この場合、ラストホップルータにはグループGの「しきい値無限大」があると言います。これは、[RFC4601]で文書化されているオプションの動作です。 「しきい値の無限大」は、RPがグループGのマルチキャストソースとマルチキャストレシーバーの間にある配置、つまり、ソースからグループの任意のレシーバーへの最短パスがRPを通過することがわかっている配置でよく使用されます。 。これらの展開では、データが既に最短パスに沿って移動しているため、ラストホップルーターがソースツリーに参加する利点はありません。ソースツリーに参加してソースを共有ツリーからプルーニングするための複雑な手順を実行する唯一の効果は、ネットワークで維持する必要があるマルチキャストルーティング状態の量を増やすことです。
To efficiently use mLDP in-band signaling in this scenario, it is necessary for the Egress LSRs to construct an Opaque Value TLV that identifies a (*,G) tree. This is done by using the wildcard in the IP source address subfield and setting the IP group address subfield to G.
このシナリオでmLDPインバンドシグナリングを効率的に使用するには、出力LSRが（*、G）ツリーを識別する不透明値TLVを構築する必要があります。これは、IPソースアドレスサブフィールドでワイルドカードを使用し、IPグループアドレスサブフィールドをGに設定することによって行われます。
Note that these mLDP in-band signaling procedures do not support PIM-ASM in scenarios where "threshold infinity" is not used.
これらのmLDPインバンドシグナリング手順は、「しきい値の無限大」が使用されないシナリオではPIM-ASMをサポートしないことに注意してください。
There are scenarios where the multicast senders and receivers are directly connected to an MPLS routing domain, and where it is desired to use mLDP rather than PIM to set up "trees" through that domain.
マルチキャストの送信側と受信側がMPLSルーティングドメインに直接接続され、そのドメインを介して「ツリー」を設定するためにPIMではなくmLDPを使用することが望ましいシナリオがあります。
In these scenarios, we can apply "IGMP/MLD proxying" and eliminate the use of PIM. The senders and receivers consider the MPLS domain to be single hop between each other. [RFC4605] documents procedures where a multicast routing protocol is not necessary to build a "simple tree". Within the MPLS domain, mLDP will be used to build an MP-LSP, but this is hidden from the senders and receivers. The procedures defined in [RFC4605] are applicable since the senders and receivers are considered to be one hop away from each other.
これらのシナリオでは、「IGMP / MLDプロキシ」を適用して、PIMの使用を排除できます。送信側と受信側は、MPLSドメインを相互間のシングルホップと見なします。 [RFC4605]は、「単純なツリー」を構築するためにマルチキャストルーティングプロトコルが不要な手順について説明しています。 MPLSドメイン内では、MPDP-LSPの構築にmLDPが使用されますが、これは送信者と受信者から隠されています。 [RFC4605]で定義されている手順は、送信側と受信側が互いに1ホップ離れていると見なされるため、適用できます。
For mLDP to build the necessary MP-LSP, it needs to know the root of the tree. Following the procedures as defined in [RFC4605], we depend on manual configuration of the mLDP root for the ASM multicast group. Since the MP-LSP for a given ASM multicast group will carry traffic from all the sources for that group, the Opaque Value TLV used to construct the MP-LSP will contain a wildcard in the IP source address subfield.
mLDPが必要なMP-LSPを構築するには、ツリーのルートを知っている必要があります。 [RFC4605]で定義されている手順に従って、ASMマルチキャストグループのmLDPルートの手動構成に依存します。特定のASMマルチキャストグループのMP-LSPは、そのグループのすべてのソースからのトラフィックを運ぶため、MP-LSPの構築に使用される不透明値TLVには、IPソースアドレスサブフィールドにワイルドカードが含まれます。
In many IPTV deployments, the content servers are gathered into a small number of sites. Popular channels are often statically configured and forwarded over a core MPLS network to the Egress routers. Since these channels are statically defined, they MAY also be forwarded over a multipoint LSP with wildcard encoding. The sort of wildcard encoding that needs to be used (source and/or group) depends on the source/group allocation policy of the IPTV provider. Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery" procedures [RFC6513] for source discovery by the Ingress LSR. Based on the received wildcard, the Ingress LSR can select from the set of IP multicast streams for which it has state.
多くのIPTV展開では、コンテンツサーバーは少数のサイトに集められます。多くの場合、人気のあるチャネルは静的に構成され、コアMPLSネットワークを介して出力ルーターに転送されます。これらのチャネルは静的に定義されているため、ワイルドカードエンコーディングを使用してマルチポイントLSPを介して転送することもできます。使用する必要のあるワイルドカードエンコーディングの種類（ソースおよび/またはグループ）は、IPTVプロバイダーのソース/グループ割り当てポリシーによって異なります。その他のオプションは、MSDP [RFC3618]またはBGP「自動検出」手順[RFC6513]を使用して、入力LSRによるソース検出を行うことです。受信したワイルドカードに基づいて、Ingress LSRは、状態があるIPマルチキャストストリームのセットから選択できます。
The decision to use mLDP in-band signaling is made by the IP multicast component of an Egress LSR, based on provisioned policy. The decision to use (or not to use) a wildcard in the IP source address subfield of an mLDP Opaque Value TLV is also made by the IP multicast component, again based on provisioned policy. Following are some example policies that may be useful: 1. Suppose that PIM is enabled, an Egress LSR needs to join a non-bidirectional ASM group G, and the RP for G is reachable via a BGP route. The Egress LSR may choose the BGP Next Hop of the route to the RP to be the Ingress LSR (root node) of the MP-LSP corresponding to the (*,G) tree (see also Section 7). The Egress LSR may identify the (*,G) tree by using an mLDP Opaque Value TLV whose IP source address subfield contains a wildcard, and whose IP group address subfield contains G.
mLDPインバンドシグナリングを使用するかどうかの決定は、プロビジョニングされたポリシーに基づいて、出力LSRのIPマルチキャストコンポーネントによって行われます。 mLDP Opaque Value TLVのIP送信元アドレスサブフィールドでワイルドカードを使用する（または使用しない）決定も、プロビジョニングされたポリシーに基づいて、IPマルチキャストコンポーネントによって行われます。以下は、役立つ可能性のあるポリシーの例です。1. PIMが有効で、出力LSRが非双方向ASMグループGに参加する必要があり、GのRPがBGPルートを介して到達可能であるとします。出力LSRは、RPへのルートのBGPネクストホップを（*、G）ツリーに対応するMP-LSPの入力LSR（ルートノード）として選択できます（セクション7も参照）。出力LSRは、IPソースアドレスサブフィールドにワイルドカードが含まれ、IPグループアドレスサブフィールドにGが含まれるmLDP Opaque Value TLVを使用して、（*、G）ツリーを識別できます。
2. Suppose that PIM is not enabled for group G, and an IGMP/MLD group membership report for G has been received by an Egress LSR. The Egress LSR may determine the "proxy device" for G (see Section 4.2). It can then set up an MP-LSP for which the proxy device is the Ingress LSR. The Egress LSR needs to signal the Ingress LSR that the MP-LSP is to carry traffic belonging to group G; it does this by using an Opaque Value TLV whose IP source address subfield contains a wildcard, and whose IP group address subfield contains G.
2. PIMがグループGに対して有効になっておらず、GのIGMP / MLDグループメンバーシップレポートが出力LSRによって受信されているとします。出力LSRは、Gの「プロキシデバイス」を決定する場合があります（セクション4.2を参照）。次に、プロキシデバイスが入力LSRであるMP-LSPを設定できます。出力LSRは、MP-LSPがグループGに属するトラフィックを伝送することを入力LSRに通知する必要があります。これは、IPソースアドレスサブフィールドにワイルドカードが含まれ、IPグループアドレスサブフィールドにGが含まれる不透明値TLVを使用して行われます。
As the policies needed in any one deployment may be very different than the policies needed in another, this document does not specify any particular set of policies as being mandatory to implement.
あるデプロイメントで必要なポリシーは別のデプロイメントで必要なポリシーとは非常に異なる可能性があるため、このドキュメントでは、特定のポリシーセットを実装に必須であると指定していません。
When the Ingress LSR receives an mLDP Opaque Value TLV that has been defined for in-band signaling, the information from the subfields of that TLV is passed to the IP multicast component of the Ingress LSR. If the IP source address subfield contains a wildcard, the IP multicast component must determine how to process it. The processing MUST follow the rules below:
Ingress LSRがインバンドシグナリング用に定義されたmLDP Opaque Value TLVを受信すると、そのTLVのサブフィールドからの情報がIngress LSRのIPマルチキャストコンポーネントに渡されます。 IPソースアドレスサブフィールドにワイルドカードが含まれている場合、IPマルチキャストコンポーネントはその処理方法を決定する必要があります。処理は以下のルールに従う必要があります。
1. If PIM is enabled and the group identified in the Opaque Value TLV is a non-bidirectional ASM group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures defined in [RFC4601] are followed.
1. PIMが有効で、不透明値TLVで識別されたグループが非双方向ASMグループである場合、入力LSRは、ダウンストリームノードから（*、G）IGMP / MLDレポートを受信したかのように動作し、手順は[RFC4601]に従います。
2. If PIM is enabled and the identified group is a PIM-SSM group, all multicast sources known for the group on the Ingress LSR are to be forwarded down the MP-LSP. In this scenario, it is assumed that the Ingress LSR is already receiving all the necessary traffic. How the Ingress LSR receives this traffic is outside the scope of this document.
2. PIMが有効で、識別されたグループがPIM-SSMグループである場合、入力LSR上のグループで認識されているすべてのマルチキャストソースがMP-LSPに転送されます。このシナリオでは、入力LSRが必要なすべてのトラフィックをすでに受信していると想定されています。 Ingress LSRがこのトラフィックを受信する方法は、このドキュメントの範囲外です。
3. If PIM is not enabled for the identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. The Ingress LSR should forward the (*,G) packets to the Egress LSR through the MP-LSP identified by the Opaque Value TLV. (See also Section 4.2.)
3. 識別されたグループでPIMが有効になっていない場合、イングレスLSRは、ダウンストリームノードから（*、G）IGMP / MLDレポートを受信したかのように動作し、[RFC4605]で定義されている手順に従います。入力LSRは、（*、G）パケットを、不透明値TLVで識別されるMP-LSPを介して出力LSRに転送する必要があります。 （セクション4.2も参照してください。）
The decision to use mLDP in-band signaling is made by the IP multicast component of an Egress LSR based on provisioned policy. The decision to use (or not to use) a wildcard in the IP group address subfield of an mLDP Opaque Value TLV is also made by the IP multicast component of the Egress LSR, again based on provisioned policy. As the policies needed in any one deployment may be very different than the policies needed in another, this document does not specify any particular set of policies as being mandatory to implement.
mLDPインバンドシグナリングを使用するかどうかの決定は、プロビジョニングされたポリシーに基づいて、出力LSRのIPマルチキャストコンポーネントによって行われます。 mLDP Opaque Value TLVのIPグループアドレスサブフィールドでワイルドカードを使用する（または使用しない）かどうかの決定も、やはりプロビジョニングされたポリシーに基づいて、出力LSRのIPマルチキャストコンポーネントによって行われます。あるデプロイメントで必要なポリシーは別のデプロイメントで必要なポリシーとは非常に異なる可能性があるため、このドキュメントでは、特定のポリシーセットを実装に必須であると指定していません。
When the Ingress LSR (i.e., the root node of the MP-LSP) receives an mLDP Opaque Value TLV that has been defined for in-band signaling, the information from the subfields of that TLV is passed to the IP multicast component of the Ingress LSR. If the IP group address subfield contains a wildcard, then the Ingress LSR examines its IP multicast routing table to find all the IP multicast streams whose IP source address is the address specified in the IP source address subfield of the TLV. All these streams SHOULD be forwarded down the MP-LSP identified by the Opaque Value TLV. Note that some of these streams may have SSM group addresses, while some may have ASM group addresses.
Ingress LSR（つまり、MP-LSPのルートノード）がインバンドシグナリング用に定義されたmLDP Opaque Value TLVを受信すると、そのTLVのサブフィールドからの情報がIngressのIPマルチキャストコンポーネントに渡されますLSR。 IPグループアドレスサブフィールドにワイルドカードが含まれている場合、入力LSRはIPマルチキャストルーティングテーブルを調べて、TLVのIPソースアドレスサブフィールドで指定されたアドレスをIPソースアドレスとするすべてのIPマルチキャストストリームを見つけます。これらのストリームはすべて、不透明値TLVによって識別されるMP-LSPに転送する必要があります（SHOULD）。これらのストリームには、SSMグループアドレスが含まれている場合と、ASMグループアドレスが含まれている場合があります。
[RFC6826] and [RFC7246] describe procedures by which an Egress LSR may determine the MP-LSP root node address corresponding to a given (S,G) IP multicast stream. That determination is based upon the IP address of the source ("S") of the multicast stream. To follow the procedures of this document, it is necessary to determine the MP-LSP root node corresponding to a given (*,G) set of IP multicast streams. The only difference from the above mentioned procedures is that the Proxy device or RP address is used instead of the source to discover the mLDP root node address.
[RFC6826]と[RFC7246]は、出力LSRが特定の（S、G）IPマルチキャストストリームに対応するMP-LSPルートノードアドレスを決定する手順を説明しています。その決定は、マルチキャストストリームのソース（ "S"）のIPアドレスに基づいています。このドキュメントの手順に従うには、IPマルチキャストストリームの特定の（*、G）セットに対応するMP-LSPルートノードを決定する必要があります。上記の手順との唯一の違いは、ソースの代わりにプロキシデバイスまたはRPアドレスを使用して、mLDPルートノードアドレスを検出することです。
Other procedures for determining the root node are also allowed, as determined by policy.
ルートノードを決定するための他の手順も、ポリシーで決定されているように許可されます。
In the scenarios where mLDP in-band signaling is used, it is unlikely that the RP-to-group mappings are being dynamically distributed over the MPLS core. It is more likely that the RP address is statically configured at each multicast site. In these scenarios, it is advisable to configure an Anycast RP address at each site in order to provide redundancy. See [RFC3446] for more details.
mLDPインバンドシグナリングが使用されるシナリオでは、RPからグループへのマッピングがMPLSコアを介して動的に分散されることはほとんどありません。 RPアドレスは、各マルチキャストサイトで静的に構成されている可能性が高くなります。これらのシナリオでは、冗長性を提供するために、各サイトでエニーキャストRPアドレスを構成することをお勧めします。詳細については、[RFC3446]を参照してください。
There are no security considerations other than ones already mentioned in [RFC5036], [RFC6826], and [RFC7246].
[RFC5036]、[RFC6826]、および[RFC7246]ですでに言及されているもの以外、セキュリティに関する考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月、< http://www.rfc-editor.org/info/rfc4601>。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"） "、RFC 4605、2006年8月、<http://www.rfc-editor.org/info/rfc4605>。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月、<http://www.rfc-editor.org/info/rfc5036>。
[RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, January 2013, <http://www.rfc-editor.org/info/rfc6826>.
[RFC6826] Wijnands、IJ。、Eckert、T.、Leymann、N。、およびM. Napierala、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのマルチポイントLDPインバンドシグナリング」、RFC 6826、 2013年1月、<http://www.rfc-editor.org/info/rfc6826>。
[RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W., Gulko, A., and J. Tantsura, "Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context", RFC 7246, June 2014, <http://www.rfc-editor.org/info/rfc7246>.
[RFC7246] Wijnands、IJ。、Hitchen、P.、Leymann、N.、Henderickx、W.、Gulko、A。、およびJ. Tantsura、「仮想ルーティングおよび転送におけるマルチポイントラベル配布プロトコルインバンドシグナリング（VRF ）Table Context "、RFC 7246、2014年6月、<http://www.rfc-editor.org/info/rfc7246>。
[GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-mvpn-global-table-mcast-00, November 2014.
[GTM] Zhang、J.、Giulano、L.、Rosen、E.、Subramanian、K.、Pacella、D.、J。Schiller、「BGP-MVPNプロシージャを使用したグローバルテーブルマルチキャスト」、作業中、ドラフト- ietf-bess-mvpn-global-table-mcast-00、2014年11月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003, <http://www.rfc-editor.org/info/rfc3446>.
[RFC3446] Kim、D.、Meyer、D.、Kilmer、H。、およびD. Farinacci、「Protocol Independent Multicast（PIM）and Multicast Source Discovery Protocol（MSDP）を使用したエニーキャストRendevous Point（RP）メカニズム」、RFC 3446 、2003年1月、<http://www.rfc-editor.org/info/rfc3446>。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003, <http://www.rfc-editor.org/info/rfc3618>.
[RFC3618] Fenner、B。およびD. Meyer、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月、<http://www.rfc-editor.org/info/rfc3618>。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月、<http：//www.rfc- editor.org/info/rfc5015>。
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513] Rosen、E。およびR. Aggarwal、「Multicast in MPLS / BGP IP VPNs」、RFC 6513、2012年2月、<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, 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、2012年2月、<http：// www .rfc-editor.org / info / rfc6514>。
Acknowledgements
謝辞
We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and Curtis Villamizar for their review and comments.
Loa Andersson、Pranjal Dutta、Lizhong Jin、Curtis Villamizarのレビューとコメントに感謝します。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（編集者）Cisco Systems、Inc. Kleetlaan 6a Diegem 1831ベルギー
EMail: ice@cisco.com
Eric C. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States
Eric C. Rosen Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
EMail: erosen@juniper.net
Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States
Arkadiy Gulko Thomson Reuters 195 Broadway New York、NY 10007アメリカ
EMail: arkadiy.gulko@thomsonreuters.com
Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 Germany
Uwe Joorde Deutsche Telekom Hammer Str。216-226 Muenster D-48153 Germany
EMail: Uwe.Joorde@telekom.de
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States
Jeff Tantsura Ericsson 300 Holger Way San Jose、CA 95134アメリカ合衆国
EMail: jeff.tantsura@ericsson.com