[要約] 要約： RFC 7442は、Multipoint LDP（mLDP）上のAny-Source Multicast（ASM）モードツリーでのProtocol Independent Multicast - Sparse Mode（PIM-SM）の実装に関する標準仕様です。目的： このRFCの目的は、mLDPを使用してASMモードツリー上でPIM-SMをサポートするための手順と要件を定義することです。これにより、異なるプロトコル間でのマルチキャスト通信の相互運用性が向上します。
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）上のAny-Source Multicast（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.
[RFC6826]は、mLDP [RFC6388]によって作成されたポイントツーマルチポイントラベルスイッチドパス（P2MP LSP）を、ソース固有のマルチキャスト（SSM）モードのプロトコル非依存マルチキャスト-スパースモード（PIM-SM）によって作成されたマルチキャストツリーにマップする方法を説明します[RFC4607]。このドキュメントでは、mLDP P2MPツリーを、Any-Source Multicast（ASM）モードでPIM-SMによって作成されたマルチキャストツリーにマップする方法について説明します。これを行うための2つの可能なメカニズムについて説明します。
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つのメカニズムは相互に排他的であることに注意してください。つまり、同じネットワーク上で、どちらか一方のメカニズムを展開できますが、両方を展開することはできません。
The reader of this document is expected to be familiar with PIM-SM [RFC4601] and mLDP [RFC6388].
このドキュメントの読者は、PIM-SM [RFC4601]およびmLDP [RFC6388]に精通していることが求められます。
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]で説明されているように解釈されます。
This mechanism does not transit IP multicast shared trees over the MPLS network. Therefore, when an LSR creates (*,G) state (as a result of receiving PIM messages on one of its IP multicast interfaces), the LSR does not propagate this state in mLDP.
このメカニズムは、MPLSネットワークを介してIPマルチキャスト共有ツリーを転送しません。したがって、LSRが（*、G）状態を作成するとき（そのIPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果）、LSRはこの状態をmLDPに伝播しません。
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はソースアクティブ自動検出ルートを撤回する必要があります。
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のソースアクティブ自動検出ルートがあるかどうかを確認する必要があります。そのようなルートがある場合、そのルートの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）エントリが含まれているかどうかを確認する必要があります。そのようなエントリが見つかった場合、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。
This mechanism enables transit of IP multicast shared trees over the MPLS network. Therefore, when an LSR creates (*,G) state as a result of receiving PIM messages on one of its IP multicast interfaces, the LSR propagates this state in mLDP, as described below.
このメカニズムにより、MPLSネットワークを介したIPマルチキャスト共有ツリーの転送が可能になります。したがって、LSRがIPマルチキャストインターフェイスの1つでPIMメッセージを受信した結果として（*、G）状態を作成すると、LSRはこの状態をmLDPで伝達します。
Note that in the deployment scenarios where, for a given G, none of the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6 Source TLV, no Source Active auto-discovery routes will be used. One other scenario where no Source Active auto-discovery routes will be used is described in Section 3.2 ("Originating Source Active Auto-discovery Routes (Mechanism 2)"). In all of these scenarios, the only part of Mechanism 2 that is used is the in-band signaling for IP Multicast Shared Trees, as described in the next section.
特定のGについて、どのPEも（S、G）mLDPラベルマップを発信IPv4 / IPv6送信元TLVで生成しない導入シナリオでは、送信元アクティブ自動検出ルートは使用されないことに注意してください。ソースアクティブ自動検出ルートが使用されないもう1つのシナリオについては、セクション3.2（「ソースアクティブ自動検出ルートの発生（メカニズム2）」）で説明します。これらすべてのシナリオで、使用されるメカニズム2の唯一の部分は、次のセクションで説明するように、IPマルチキャスト共有ツリーのインバンドシグナリングです。
To provide support for in-band mLDP signaling of IP multicast shared trees, this document defines two new mLDP TLVs: the Transit IPv4 Shared Tree TLV and the Transit IPv6 Shared Tree TLV.
IPマルチキャスト共有ツリーのインバンドmLDPシグナリングをサポートするために、このドキュメントでは、2つの新しいmLDP TLVを定義します。それは、通過IPv4共有ツリーTLVと通過IPv6共有ツリーTLVです。
These two TLVs have exactly the same encoding/format as the IPv4/IPv6 Source Tree TLVs defined in [RFC6826], except that instead of the Source field they have an RP field that carries the address of the RP, as follows:
これらの2つのTLVは、[RFC6826]で定義されているIPv4 / IPv6ソースツリーTLVとまったく同じエンコーディング/フォーマットを持っていますが、ソースフィールドの代わりに、次のようにRPのアドレスを運ぶRPフィールドがある点が異なります。
Transit IPv4 Shared Tree TLV:
中継IPv4共有ツリーTLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11
タイプ：11
Length: 8
長さ：8
RP: IPv4 RP address, 4 octets.
RP：IPv4 RPアドレス、4オクテット。
Group: IPv4 multicast group address, 4 octets.
グループ：IPv4マルチキャストグループアドレス、4オクテット。
Transit IPv6 Shared Tree TLV:
トランジットIPv6共有ツリーTLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12
タイプ：12
Length: 32
長さ：32
RP: IPv6 RP address, 16 octets.
RP：IPv6 RPアドレス、16オクテット。
Group: IPv6 multicast group address, 16 octets.
グループ：IPv6マルチキャストグループアドレス、16オクテット。
Procedures for in-band signaling for IP multicast shared trees with mLDP follow the same procedures as those for in-band signaling for IP multicast source trees, as specified in [RFC6826], except that while the latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs.
mLDPを使用したIPマルチキャスト共有ツリーのインバンドシグナリングの手順は、[RFC6826]で指定されているIPマルチキャストソースツリーのインバンドシグナリングの手順と同じですが、後者の信号（S、G）はトランジットIPv4 / IPv6ソースTLV。以前の信号（*、G）は、トランジットIPv4 / IPv6共有ツリーTLVを使用します。
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自動検出ルートを発信する必要があります。以下が当てはまります。
+ 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はソースアクティブ自動検出も取り消す必要がありますroute、状態が作成されたときにそのようなルートがアドバタイズされた場合。
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の手順と同じです。
If, after receiving a new Source Active auto-discovery route for (S,G), the LSR determines that (a) it has the (*,G) entry in its TIB, (b) the incoming interface (iif) list for that entry contains one of the IP interfaces, (c) at least one of the MPLS interfaces is in the outgoing interface (oif) list for that entry, and (d) the LSR does not originate an mLDP Label Mapping message for (S,G) with the Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the (S,G,RPT-bit) downstream state to the Prune state. (Conceptually, the PIM state machine on the LSR will act "as if" it had received Prune(S,G,rpt) on one of its MPLS interfaces, without actually having received one.) Depending on the (S,G,RPT-bit) state on the iif, this may result in the LSR using PIM procedures to prune S off the Shared (*,G) tree.
（S、G）の新しいソースアクティブ自動検出ルートを受信した後、LSRは（a）TIBに（*、G）エントリがあると判断した場合、（b）の着信インターフェイス（iif）リストそのエントリにIPインターフェイスの1つが含まれている、（c）MPLSインターフェイスの少なくとも1つがそのエントリの発信インターフェイス（oif）リストにある、（d）LSRが（S、 G）Transit IPv4 / IPv6 Source TLVの場合、LSRは（S、G、RPT-bit）ダウンストリーム状態をプルーン状態に遷移しなければなりません（MUST）。 （概念的には、LSR上のPIMステートマシンは、MPLSインターフェイスの1つでPrune（S、G、rpt）を受信したかのように動作しますが、実際には受信していません。）（S、G、RPT -bit）iifの状態。これにより、LSRがPIMプロシージャを使用して、共有（*、G）ツリーからSをプルーニングする場合があります。
The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the Prune state for as long as (a) the outgoing interface (oif) list for (*,G) contains one of the MPLS interfaces, (b) the LSR has at least one Source Active auto-discovery route for (S,G), and (c) the LSR does not originate the mLDP Label Mapping message for (S,G) with the Transit IPv4/IPv6 Source TLV. Once one or more of these conditions become no longer valid, the LSR MUST transition the (S,G,RPT-bit) downstream state machine to the NoInfo state.
LSRは、（a）（*、G）の発信インターフェース（oif）リストにMPLSインターフェースの1つが含まれている限り、（S、G、RPTビット）ダウンストリームステートマシンをプルーン状態に維持する必要があります（b ）LSRには（S、G）のソースアクティブ自動検出ルートが少なくとも1つあり、（c）LSRは（S、G）のmLDPラベルマッピングメッセージをTransit IPv4 / IPv6 Source TLVで発信しません。これらの条件の1つ以上が無効になると、LSRは（S、G、RPT-bit）ダウンストリームステートマシンをNoInfoステートに遷移する必要があります（MUST）。
Note that except for the scenario described in the first paragraph of this section, it is sufficient to rely solely on the PIM procedures on the LSR to ensure the correct behavior when pruning sources off the shared tree.
このセクションの最初の段落で説明されているシナリオを除いて、共有ツリーからソースをプルーニングするときの正しい動作を保証するには、LSRのPIM手順のみに依存するだけで十分です。
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つの新しい値を割り当てました。
Value | Name | Reference
------+------------------------------+------------
11 | Transit IPv4 Shared Tree TLV | [RFC7442]
12 | Transit IPv6 Shared Tree TLV | [RFC7442]
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。、および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。、および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。、および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.および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>。
Acknowledgements
謝辞
The use of Source Active auto-discovery routes was borrowed from [RFC6514]. Some text in this document was borrowed from [RFC6514].
Source Active自動検出ルートの使用は、[RFC6514]から借用されました。この文書の一部のテキストは、[RFC6514]から借用したものです。
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のレビューとコメントにも感謝します。
Authors' Addresses
著者のアドレス
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