[要約] RFC 7442は、Multipoint LDP（mLDP）によって構築されたAny-Source Multicast（ASM）ツリー上で、PIM-SMプロトコルを透過的に動作させるための仕様を定義しています。マルチポイントラベル交換パスを介してPIM制御メッセージをやり取りするための、カプセル化とシグナリングのマッピング手順を規定しています。MPLSコアネットワークにおいて、既存のPIMベースのマルチキャストサービスを効率的に収容・統合することを目的としています。
Internet Engineering Task Force (IETF) Y. Rekhter
Request for Comments: 7442 Juniper Networks
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan
N. Leymann
Deutsche Telekom
W. Henderickx
Alcatel-Lucent
Q. Zhao
R. Li
Huawei
February 2015
Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)
マルチポイントLDP（mLDP）上の全送信源マルチキャスト（ASM）モードツリーにおけるプロトコル独立マルチキャスト - スパースモード（PIM-SM）の転送
Abstract
概要
When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).
Any-Source Multicast（ASM）モードのProtocol Independent Multicast-Sparse Mode（PIM-SM）によって作成されたIPマルチキャストツリーがMPLSドメインを通過する必要がある場合、そのようなツリーをポイントツーマルチポイントラベルスイッチにマップすることが望ましい場合があります。パス（P2MP LSP）。このドキュメントでは、このようなP2MP LSPがP2MPおよびマルチポイントツーマルチポイントLSPのラベル配布プロトコル（LDP）拡張を使用して確立されている場合にこれを達成する方法について説明します：マルチポイントLDP（mLDP）。
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/rfc7442.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7442で入手できます。
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 1.1. Specification of Requirements ..............................4 2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees ....................................................4 2.1. Originating Source Active Auto-discovery Routes (Mechanism 1) ..............................................4 2.2. Receiving Source Active Auto-discovery Routes by LSR .......5 2.3. Handling (S,G,RPT-bit) State ...............................5 3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...6 3.1. In-Band Signaling for IP Multicast Shared Trees ............6 3.2. Originating Source Active Auto-discovery Routes (Mechanism 2) ..............................................7 3.3. Receiving Source Active Auto-discovery Routes ..............8 3.4. Pruning Sources Off the Shared Tree ........................8 3.5. More on Handling (S,G,RPT-bit) State .......................9 4. IANA Considerations .............................................9 5. Security Considerations .........................................9 6. References .....................................................10 6.1. Normative References ......................................10 6.2. Informative References ....................................10 Acknowledgements ..................................................11 Authors' Addresses ................................................11
[RFC6826] describes how to map Point-to-Multipoint Label Switched Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Source-Specific Multicast (SSM) mode [RFC4607]. This document describes how to map mLDP P2MP trees to multicast trees created by PIM-SM in Any-Source Multicast (ASM) mode. It describes two possible mechanisms for doing this.
The first mechanism, described in Section 2, is OPTIONAL for implementations, but the second mechanism, described in Section 3, is REQUIRED for all implementations claiming conformance to this specification.
セクション2で説明されている最初のメカニズムは実装ではオプションですが、セクション3で説明されている2番目のメカニズムは、この仕様への適合を主張するすべての実装で必須です。
Note that from a deployment point of view these two mechanisms are mutually exclusive. That is, on the same network one could deploy either one of the mechanisms, but not both.
デプロイメントの観点から、これら2つのメカニズムは相互に排他的であることに注意してください。つまり、同じネットワーク上で、どちらか一方のメカニズムを展開できますが、両方を展開することはできません。
This document relies on the procedures in [RFC6826] to support source trees. For example, following these procedures a Label Switching Router (LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join.
このドキュメントは、ソースツリーをサポートするために[RFC6826]の手順に依存しています。たとえば、これらの手順に従って、ラベルスイッチングルータ（LSR）は、PIM（S、G）加入を受信すると、（S、G）のTransit IPv4/IPv6 Source TLVでmLDPラベルマップを開始できます。
This document uses BGP Source Active auto-discovery routes, as defined in [RFC6514]. For the sake of brevity in the rest of this document, we'll refer to these routes as just "Source Active auto-discovery routes".
このドキュメントでは、[RFC6514]で定義されているBGPソースアクティブ自動検出ルートを使用します。このドキュメントの残りの部分では簡潔にするために、これらのルートを単に「ソースアクティブな自動検出ルート」と呼びます。
Consider a deployment scenario where the service provider has provisioned the network in such a way that the Rendezvous Point (RP) for a particular ASM group G is always between the receivers and the sources. If the network is provisioned in this manner, the ingress Provider Edge (PE) for (S,G) is always the same as the ingress PE for the RP, and thus the Source Active auto-discovery (A-D) routes are never needed. If it is known a priori that the network is provisioned in this manner, mLDP in-band signaling can be supported using a different set of procedures, as specified in [RFC7438]. A service provider will provision the PE routers to use either the procedures in [RFC7438] or those described in this document.
特定のASMグループGのランデブーポイント（RP）が常にレシーバーとソースの間にあるようにサービスプロバイダーがネットワークをプロビジョニングした配備シナリオを考えてみます。ネットワークがこのようにプロビジョニングされている場合、（S、G）の入力プロバイダーエッジ（PE）は常にRPの入力PEと同じであるため、ソースアクティブ自動検出（A-D）ルートは必要ありません。ネットワークがこのようにプロビジョニングされていることが事前にわかっている場合、[RFC7438]で指定されているように、mLDPインバンドシグナリングは異なる手順のセットを使用してサポートできます。サービスプロバイダーは、[RFC7438]の手順またはこのドキュメントで説明されている手順のいずれかを使用するようにPEルータをプロビジョニングします。
Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP LSP in the MPLS network. This type of service works well if the number of LSPs that are created is under the control of the MPLS network operator, or if the number of LSPs for a particular service is known to be limited.
[RFC6826]と同様に、各IPマルチキャストツリーは、MPLSネットワークのP2MP LSPに1対1でマッピングされます。このタイプのサービスは、作成されるLSPの数がMPLSネットワークオペレーターの制御下にある場合、または特定のサービスのLSPの数が制限されていることがわかっている場合にうまく機能します。
It is to be noted that the existing BGP Multicast VPN (MVPN) procedures [RFC6514] can be used to map Internet IP multicast trees to P2MP LSPs. These procedures would accomplish this for IP multicast trees created by PIM-SM in SSM mode, as well as for IP multicast trees created by PIM-SM in ASM mode. Furthermore, these procedures would also support the ability to aggregate multiple IP multicast trees to one P2MP LSP in the MPLS network. The details of this particular approach are out of scope for this document.
既存のBGPマルチキャストVPN（MVPN）手順[RFC6514]を使用して、インターネットIPマルチキャストツリーをP2MP LSPにマップできることに注意してください。これらの手順は、SSMモードのPIM-SMによって作成されたIPマルチキャストツリーと、ASMモードのPIM-SMによって作成されたIPマルチキャストツリーに対してこれを実現します。さらに、これらの手順は、MPLSネットワーク内の1つのP2MP LSPに複数のIPマルチキャストツリーを集約する機能もサポートします。この特定のアプローチの詳細は、このドキュメントの範囲外です。
This document assumes that a given LSR may have some interfaces that are IP multicast capable, while other interfaces would be MPLS capable.
このドキュメントでは、特定のLSRにIPマルチキャスト対応のインターフェイスがいくつかあり、他のインターフェイスはMPLS対応であると想定しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されているように解釈されるものとします。
Whenever (as a result of receiving either PIM Register or Multicast Source Discovery Protocol (MSDP) messages) an RP discovers a new multicast source, the RP SHOULD originate a Source Active auto-discovery route. The route carries a single MCAST-VPN Network Layer Reachability Information (NLRI) [RFC6514], constructed as follows:
（PIM RegisterまたはMulticast Source Discovery Protocol（MSDP）メッセージを受信した結果として）RPが新しいマルチキャストソースを検出するたびに、RPはソースアクティブ自動検出ルートを開始すべきです (SHOULD)。ルートは、次のように構築された単一のMCAST-VPNネットワーク層到達可能性情報（NLRI）[RFC6514]を伝送します。
+ The Route Distinguisher (RD) in this NLRI is set to 0.
+ このNLRIのRoute Distinguisher（RD）は0に設定されています。
+ The Multicast Source field is set to S. This could be either an IPv4 or an IPv6 address. The Multicast Source Length field is set appropriately to reflect the address type.
+ Multicast SourceフィールドはSに設定されています。これはIPv4またはIPv6アドレスのいずれかです。 Multicast Source Lengthフィールドは、アドレスタイプを反映するように適切に設定されています。
+ The Multicast Group field is set to G. This could be either an IPv4 or an IPv6 address. The Multicast Group Length field is set appropriately to reflect this address type.
+ Multicast GroupフィールドはGに設定されています。これはIPv4またはIPv6アドレスのいずれかです。 Multicast Group Lengthフィールドは、このアドレスタイプを反映するように適切に設定されています。
To constrain distribution of the Source Active auto-discovery route to the Autonomous System (AS) of the advertising RP, this route SHOULD carry the NO_EXPORT Community ([RFC1997]).
アドバタイジングRPの自律システム（AS）へのソースアクティブ自動検出ルートの配布を制限するために、このルートはNO_EXPORTコミュニティ（[RFC1997]）を伝送すべきです (SHOULD)。
Using the normal BGP procedures, the Source Active auto-discovery route is propagated to all other LSRs within the AS.
通常のBGP手順を使用して、ソースアクティブ自動検出ルートはAS内の他のすべてのLSRに伝播されます。
Whenever the RP discovers that the source is no longer active, the RP MUST withdraw the Source Active auto-discovery route if such a route was previously advertised by the RP.
ソースがアクティブではなくなったことをRPが検出したときは常に、そのようなルートが以前にRPによってアドバタイズされていた場合、RPはソースアクティブ自動検出ルートを撤回しなければなりません (MUST)。
Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast.
IPマルチキャストに対応しているインターフェースとMPLSマルチキャストに対応しているインターフェースがあるLSRについて考えてみます。
When, as a result of receiving PIM messages on one of its IP multicast interfaces, an LSR creates in its Tree Information Base (TIB) a new (*,G) entry with a non-empty outgoing interface list that contains one or more IP multicast interfaces, the LSR MUST check to see if it has any Source Active auto-discovery routes for that G. If there is such a route, S of that route is reachable via an MPLS interface, and the LSR does not have (S,G) state in its TIB for (S,G) carried in the route, then the LSR originates the mLDP Label Map with the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826].
IPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果、LSRがツリー情報ベース（TIB）に、1つ以上のIPを含む空でない発信インターフェイスリストを含む新しい（*、G）エントリを作成する場合マルチキャストインターフェイスの場合、LSRはそのGのソースアクティブ自動検出ルートがあるかどうかを確認しなければなりません (MUST)。そのようなルートがある場合、そのルートのSはMPLSインターフェイス経由で到達可能であり、LSRには（S、 G）ルートで運ばれる（S、G）のTIBの状態。LSRは、[RFC6826]で指定されているように、（S、G）を運ぶトランジットIPv4/IPv6ソースTLVでmLDPラベルマップを生成します。
When an LSR receives a new Source Active auto-discovery route, the LSR MUST check to see if its TIB contains a (*,G) entry with the same G as that carried in the Source Active auto-discovery route. If such an entry is found, S is reachable via an MPLS interface, and the LSR does not have (S,G) state in its TIB for (S,G) carried in the route, then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826].
LSRが新しいソースアクティブ自動検出ルートを受信すると、LSRはそのTIBにソースアクティブ自動検出ルートで運ばれたものと同じGの（*、G）エントリが含まれているかどうかを確認しなければなりません (MUST)。そのようなエントリが見つかった場合、SはMPLSインターフェイスを介して到達可能であり、LSRはルートで運ばれる（S、G）のTIBに（S、G）状態を持っていないので、LSRはmLDPラベルマップを発信します。 [RFC6826]で指定されているように、（S、G）を運ぶTransit IPv4/IPv6 Source TLV。
The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on an LSR that resulted from receiving PIM messages on one of its IP multicast interfaces do not result in any mLDP and/or BGP actions by the LSR.
LSRで（S、G、RPT-bit）PIM状態（[RFC4601]）を作成および削除すると、IPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果、mLDPやBGPアクションが発生しません。 LSR。
Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast.
IPマルチキャストに対応しているインターフェースとMPLSマルチキャストに対応しているインターフェースがあるLSRについて考えてみます。
Whenever such an LSR creates an (S,G) state as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G), the LSR MUST originate a Source Active auto-discovery route if all of the following are true:
そのようなLSRが（S、G）のTransit IPv4/IPv6 Source TLVを使用してmLDPラベルマップを受信した結果として（S、G）状態を作成する場合、LSRはすべての場合、Source Active自動検出ルートを発信しなければなりません (MUST)。以下が当てはまります。
+ S is reachable via one of the IP-multicast-capable interfaces,
+ Sは、IPマルチキャスト対応インターフェースの1つを介して到達可能です。
+ the LSR determines that G is in the PIM-SM in ASM mode range, and
+ LSRは、GがASMモード範囲のPIM-SMにあると判断し、
+ the LSR does not have a (*,G) state with one of the IP-multicast-capable interfaces as an incoming interface (iif) for that state.
+ LSRには（*、G）状態がなく、IPマルチキャスト対応インターフェースの1つがその状態の着信インターフェース（iif）になります。
The route carries a single MCAST-VPN NLRI, constructed as follows:
ルートは、次のように構築された単一のMCAST-VPN NLRIを伝送します。
+ The RD in this NLRI is set to 0.
+ このNLRIのRDは0に設定されています。
+ The Multicast Source field is set to S. The Multicast Source Length field is set appropriately to reflect this address type.
+ Multicast SourceフィールドはSに設定されています。MulticastSource Lengthフィールドは、このアドレスタイプを反映するように適切に設定されています。
+ The Multicast Group field is set to G. The Multicast Group Length field is set appropriately to reflect this address type.
+ Multicast GroupフィールドはGに設定されています。MulticastGroup Lengthフィールドは、このアドレスタイプを反映するように適切に設定されています。
To constrain distribution of the Source Active auto-discovery route to the AS of the advertising LSR, this route SHOULD carry the NO_EXPORT Community ([RFC1997]).
ソースアクティブ自動検出ルートの配布を広告LSRのASに制限するには、このルートはNO_EXPORTコミュニティ（[RFC1997]）を伝送すべきです (SHOULD)。
Using the normal BGP procedures, the Source Active auto-discovery route is propagated to all other LSRs within the AS.
通常のBGP手順を使用して、ソースアクティブ自動検出ルートはAS内の他のすべてのLSRに伝播されます。
Whenever the LSR receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was previously created, the LSR that deletes the state MUST also withdraw the Source Active auto-discovery route, if such a route was advertised when the state was created.
（S、G）のTransit IPv4/IPv6 Source TLVでmLDPラベルマップを受信するLSRが以前に作成された（S、G）状態を削除するときはいつでも、状態を削除するLSRは、状態の作成時にSource Active自動発見経路を広告していた場合、その経路も取り消さなければなりません (MUST)。
Note that whenever an LSR creates an (S,G) state as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) with S reachable via one of the IP-multicast-capable interfaces, and the LSR already has a (*,G) state with the RP reachable via one of the IP-multicast-capable interfaces as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree TLV for (*,G), the LSR does not originate a Source Active auto-discovery route.
L-SRが、（S、G）のトランジットIPv4/IPv6ソースTLVを使用してmLDPラベルマップを受信した結果、（S、G）状態を作成し、SがIPマルチキャスト対応インターフェイスの1つを介して到達できることに注意してください。 （*、G）のTransit IPv4/IPv6共有ツリーTLVでmLDPラベルマップを受信した結果、LSRにはすでに（*、G）状態があり、RPはIPマルチキャスト対応インターフェイスの1つを介して到達可能です。 、LSRはソースアクティブ自動検出ルートを開始しません。
Procedures for receiving Source Active auto-discovery routes are the same as those for Mechanism 1.
ソースアクティブ自動検出ルートを受信する手順は、メカニズム1の手順と同じです。
The creation and deletion of (S,G,RPT-bit) state on an LSR that resulted from receiving PIM messages on one of its IP multicast interfaces do not result in any mLDP and/or BGP actions by the LSR.
IPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果、LSRで（S、G、RPT-bit）状態が作成および削除されても、LSRによるmLDPまたはBGPアクションは発生しません。
IANA maintains a registry called "Label Distribution Protocol (LDP) Parameters" with a subregistry called "LDP MP Opaque Value Element basic type". IANA has allocated two new values, as follows:
IANAは、「LDP MP Opaque Value Element basic type」というサブレジストリを持つ「Label Distribution Protocol（LDP）Parameters」というレジストリを維持しています。 IANAは、次の2つの新しい値を割り当てました。
All of the security considerations for mLDP ([RFC6388]) apply here.
ここでは、mLDP（[RFC6388]）のセキュリティに関する考慮事項がすべて適用されます。
From the security considerations point of view, the use of Shared Tree TLVs is no different than the use of Source TLVs [RFC6826].
セキュリティの観点から見ると、共有ツリーTLVの使用はソースTLV [RFC6826]の使用と同じです。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997] Chandra, R., Traina, P., and T. Li、「BGP Communities Attribute」、RFC 1997、1996年8月、<http://www.rfc-editor.org/info/rfc1997>。
[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., and I. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月、<http://www.rfc-editor.org/info/rfc4601>。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <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、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[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., and Y. Rekhter、「MPLS/BGP IP VPNにおけるマルチキャスト用のBGPエンコーディングおよび手順」、RFC 6514、2012年2月、<http://www.rfc-editor.org/info/rfc6514>。
[RFC6826] Wijnands, IJ., Ed., 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。、Ed。、Eckert、T.、Leymann、N。、およびM. Napierala、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのマルチポイントLDPインバンドシグナリング」、 RFC 6826、2013年1月、<http://www.rfc-editor.org/info/rfc6826>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006, <http://www.rfc-editor.org/ info/rfc4607>.
[RFC4607] Holbrook, H. and B. Cain、「Source-Specific Multicast for IP」、RFC 4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC7438] Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and J. Tantsura, "Multipoint LDP (mLDP) In-Band Signaling with Wildcards", RFC 7438, January 2015, <http://www.rfc-editor.org/info/rfc7438>.
[RFC7438] Wijnands、IJ。、Ed。、Rosen、E.、Gulko、A.、Joorde、U.、and J. Tantsura、 "Multipoint LDP（mLDP）In-Band Signaling with Wildcards"、RFC 7438、January 2015 、<http://www.rfc-editor.org/info/rfc7438>。
Some of the text in this document was borrowed from [RFC6826].
このドキュメントのテキストの一部は、[RFC6826]から借用されました。
We would like to acknowledge Arkadiy Gulko for his review and comments.
Arkadiy Gulkoのレビューとコメントに感謝します。
We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati, and Adrian Farrel for their review and comments.
Xuxiaohu、Gregory Mirsky、Rajiv Asati、Adrian Farrelのレビューとコメントにも感謝します。
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks、Inc. Eメール：yakov@juniper.net
Rahul Aggarwal Arktan EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Arktan Eメール：raggarwa_1@yahoo.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: N.Leymann@telekom.de
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21ベルリン10781ドイツEメール：N.Leymann@telekom.de
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucentメール：wim.henderickx@alcatel-lucent.com
Quintin Zhao Huawei EMail: quintin.zhao@huawei.com
Quintin Zhao hu Aはメール：Quintin.Find @华华.com
Richard Li Huawei EMail: renwei.li@huawei.com
リチャードl IH UAは電子メールです：think。Lee @ Huawei.com