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
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).
当在任何源多播（ASM）模式下由协议独立多播稀疏模式（PIM-SM）创建的IP多播树需要通过MPLS域时，可能需要将此类树映射到点对多点标签交换路径（P2MP LSP）。本文档描述了在使用P2MP和多点到多点LSP的标签分发协议（LDP）扩展建立P2MP LSP的情况下如何实现这一点：多点LDP（mLDP）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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）模式[RFC4607]中的协议独立多播稀疏模式（PIM-SM）创建的多播树。本文档描述如何将mLDP P2MP树映射到PIM-SM在任何源多播（ASM）模式下创建的多播树。它描述了执行此操作的两种可能机制。
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节中描述的第二种机制对于声称符合本规范的所有实现都是必需的。
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.
请注意，从部署的角度来看，这两种机制是相互排斥的。也就是说，在同一网络上，可以部署其中一种机制，但不能同时部署两种机制。
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）的传输IPv4/IPv6源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）路由。如果事先知道网络是以这种方式供应的，则可以使用不同的程序集来支持mLDP带内信令，如[RFC7438]中所述。服务提供商将提供PE路由器，以使用[RFC7438]中的程序或本文档中描述的程序。
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。如果创建的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]可用于将Internet IP多播树映射到P2MP LSP。这些过程将为在SSM模式下由PIM-SM创建的IP多播树以及在ASM模式下由PIM-SM创建的IP多播树实现这一点。此外，这些过程还支持将多个IP多播树聚合到MPLS网络中的一个P2MP LSP的能力。此特定方法的详细信息不在本文档的范围内。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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多播接口上接收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:
每当RP发现新的多播源时（作为接收PIM寄存器或多播源发现协议（MSDP）消息的结果），RP应发起一个源活动自动发现路由。路由携带单个MCAST-VPN网络层可达性信息（NLRI）[RFC6514]，构造如下：
+ The Route Distinguisher (RD) in this NLRI is set to 0.
+ 此NLRI中的路由标识符（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.
+ 多播源字段设置为S。这可能是IPv4或IPv6地址。多播源长度字段被适当设置以反映地址类型。
+ 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.
+ 多播组字段设置为G。这可能是IPv4或IPv6地址。多播组长度字段被适当设置以反映此地址类型。
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_导出社区（[RFC1997]）。
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.
考虑一个LSR，它具有一些能够IP组播和一些能够MPLS组播的接口。
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].
当LSR在其一个IP多播接口上接收PIM消息后，在其树信息库（TIB）中创建一个新的（*，G）条目，其中包含一个或多个IP多播接口的非空传出接口列表，LSR必须检查是否有该G的任何源活动自动发现路由。如果存在此类路由，则可通过MPLS接口访问该路由的S，并且LSR在其TIB中没有（S，G）状态（S，G）用于路由中携带的（S，G），则LSR使用传输IPv4/IPv6源TLV（S，G）发起mLDP标签映射，按照[RFC6826]中的规定。
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）条目。如果找到这样一个条目，可以通过MPLS接口访问S，并且LSR在其TIB中没有路由中携带的（S，G）的（S，G）状态，则LSR根据[RFC6826]中的规定，使用传输IPv4/IPv6源TLV携带（S，G）生成mLDP标签映射。
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.
由于在其一个IP多播接口上接收PIM消息而在LSR上创建和删除（S、G、RPT位）PIM状态（[RFC4601]），不会导致LSR执行任何mLDP和/或BGP操作。
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多播接口上接收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使用传输IPv4/IPv6源TLV发起（S，G）mLDP标签映射，将不使用源活动自动发现路由。第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信令，本文档定义了两个新的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:
这两个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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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多播源树的带内信令过程相同，除了后者使用传输IPv4/IPv6源TLV发送（S，G）状态信号外，前者使用传输IPv4/IPv6共享树TLV发送（*，G）状态信号。
Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast.
考虑一个LSR，它具有一些能够IP组播和一些能够MPLS组播的接口。
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）的传输IPv4/IPv6源TLV的mLDP标签映射而创建（S，G）状态时，如果以下所有条件均为真，则LSR必须发起源活动自动发现路由：
+ S is reachable via one of the IP-multicast-capable interfaces,
+ 可通过其中一个支持IP多播的接口访问，
+ 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多播的接口作为该状态的传入接口（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.
+ 多播源字段被设置为S。多播源长度字段被适当设置以反映此地址类型。
+ The Multicast Group field is set to G. The Multicast Group Length field is set appropriately to reflect this address type.
+ 多播组字段被设置为G。多播组长度字段被适当设置以反映此地址类型。
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_导出社区（[RFC1997]）。
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）的传输IPv4/IPv6源TLV的mLDP标签映射的LSR删除之前创建的（S，G）状态时，如果在创建状态时播发了此类路由，则删除该状态的LSR还必须撤回源活动自动发现路由。
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.
请注意，每当LSR由于接收到（S，G）的传输IPv4/IPv6源TLV的mLDP标签映射（S，G）而创建（S，G）状态时，可以通过一个支持IP多播的接口访问（S，G），并且LSR已经具有（*，G）如果RP可通过一个支持IP多播的接口访问，则LSR不会发起源活动自动发现路由，因为接收到带有（*，G）的传输IPv4/IPv6共享树TLV的mLDP标签映射。
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
如果在接收到（S，G）的新源活动自动发现路由后，LSR确定（a）其TIB中有（*，G）条目，（b）该条目的传入接口（iif）列表包含一个IP接口，（c）该条目的传出接口（oif）列表中至少有一个MPLS接口，以及（d）LSR不会使用传输IPv4/IPv6源TLV为（S，G）发起mLDP标签映射消息，那么LSR必须将（S，G，RPT位）下游状态转换为删除状态。（从概念上讲，LSR上的PIM状态机将“好像”它已接收到
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.
修剪其一个MPLS接口上的（S，G，rpt），而实际上没有收到。根据iif上的（S，G，rpt位）状态，这可能导致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.
只要（a）（*，G）的传出接口（oif）列表包含一个MPLS接口，（b）LSR至少有一个（S，G）的源活动自动发现路由，（c）LSR不为（S，G）发起mLDP标签映射消息，LSR就必须使（S，G，RPT位）下游状态机保持修剪状态使用传输IPv4/IPv6源TLV。一旦这些条件中的一个或多个不再有效，LSR必须将（S、G、RPT位）下游状态机转换为NoInfo状态。
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多播接口上接收PIM消息而在LSR上创建和删除（S、G、RPT位）状态不会导致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）参数”的注册表，该注册表具有一个名为“LDP MP不透明值元素基本类型”的子区域。IANA分配了两个新值，如下所示：
Value | Name | Reference
------+------------------------------+------------
11 | Transit IPv4 Shared Tree TLV | [RFC7442]
12 | Transit IPv6 Shared Tree TLV | [RFC7442]
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社区属性”，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，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年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.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，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，“IP的源特定多播”，RFC4607，2006年8月<http://www.rfc-editor.org/ 信息/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.，和J.Tantsura，“带通配符的多点LDP（mLDP）带内信令”，RFC 7438，2015年1月<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].
源活动自动发现路由的使用借用自[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.
我们要感谢阿尔卡迪·古尔科的审查和评论。
We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati, and Adrian Farrel for their review and comments.
我们还要感谢徐晓虎、格雷戈里·米尔斯基、拉吉夫·阿萨蒂和阿德里安·法雷尔的评论和评论。
Authors' Addresses
作者地址
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks，Inc.电子邮件：yakov@juniper.net
Rahul Aggarwal Arktan EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Arktan电子邮件：raggarwa_1@yahoo.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: N.Leymann@telekom.de
Nicolai Leymann德意志电信公司Winterfeldtstrasse 21柏林10781德国电子邮件：N。Leymann@telekom.de
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim亨德里克斯阿尔卡特朗讯电子邮件：Wim。henderickx@alcatel-朗讯网
Quintin Zhao Huawei EMail: quintin.zhao@huawei.com
Quintin Zhao华为电子邮件：Quintin。zhao@huawei.com
Richard Li Huawei EMail: renwei.li@huawei.com
李泽楷华为邮箱：任伟。li@huawei.com