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
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域的场景。在这些场景中，可能需要在IP多播树进入MPLS域时将其“无缝”转换为MPLS多点标签交换路径（MP-LSP），然后在其退出MPLS域时将其转换回IP多播树。以前的文档指定了允许将某些类型的IP多播树（源特定多播树或双向多播树）连接到MPLS多点标签交换路径（MP-LSP）的过程。但是，以前的文档没有指定将任何源IP多播树附加到MP LSP的过程，也没有指定将多个IP多播树聚合到单个MP-LSP上的过程。本文件规定了支持这些功能的程序。它是通过定义“通配符”编码来实现的，该编码使得在设置MP-LSP时，可以指定一组IP多播树或共享IP多播树应连接到该MP-LSP。对非双向IP任意源多播树的支持受本文档中讨论的某些适用性限制的约束。本文件更新了RFCs 6826和7246。
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/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.
版权所有（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
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
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]指定了mLDP（多点LDP）的过程，该过程允许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
在mLDP中，每个MP-LSP通过“根节点”（或“入口标签交换路由器（LSR）”）和“不透明值”的组合来标识，该不透明值在根节点的上下文中唯一标识MP-LSP。这些被编码到mLDP“转发等价类（FEC）元素”中。为了建立MP-LSP，出口LSR发起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.
包含FEC元素的控制消息。给定的FEC元素值标识单个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时，[RFC6826]和[RFC7246]的过程称为“mLDP带内信令”，允许MP-LSP的出口LSR在标识MP-LSP的mLDP FEC元素的“不透明值”字段中编码IP多播树的标识符。只有出口和入口lsr知道mLDP FEC元素包含IP组播树标识符的编码；MP-LSP沿线的中间节点不考虑FEC元素不透明值的内部结构，不透明值的内部结构不影响mLDP的操作。通过使用mLDP带内信令，MP-LSP的出口LSR通知入口LSR它们期望在MP-LSP上承载所识别的IP多播树的通信量（并且仅该通信量）。也就是说，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]中进行多播，则mLDP FEC元素还包含“路由识别器”（RD）（参见[RFC7246]），因为IP多播树不仅由“（S，G）”标识，而且由“（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
当遵循[RFC6826]和[RFC7246]中针对非双向树的过程时，不透明值具有编码到其中的IP源地址和IP组地址（G），从而使其能够识别特定的IP多播（S，G）树。在给定的FEC元素中只能识别单个IP源特定的多播树（即单个“（S，G）”。因此，给定的MP-LSP只能承载来自单个IP源特定多播树（即单个“（S，G）树）的数据。然而，在一些场景中，在一个树上聚合一些（S，G）树是可取的
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.
单一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）共享树连接到MP-LSP，除非ASM共享树是双向树（即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.
本文件规定了一种编码mLDP“不透明值”的方法，其中“S”或“G”或两者都被替换为“通配符”（写为“*”）。描述了使用通配符编码将非双向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过程。在[RFC6826]和[RFC7246]中可以找到不特定于使用通配符的mLDP带内信令过程。除非本文档中另有规定，否则在使用通配符时，这些过程仍然适用。
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：Internet组管理协议。
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多播树：由IP多播组地址和可选源IP地址标识的IP多播分发树，也称为（S，G）和（*，G）。
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：独立于协议的多播。
PIM-ASM: PIM Any-Source Multicast.
PIM-ASM:PIM任何源多播。
PIM-SM: PIM Sparse Mode.
PIM-SM：PIM稀疏模式。
PIM-SSM: PIM Source-Specific Multicast.
PIM-SSM:PIM源特定多播。
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多播数据包的LSP，并将该数据作为IP多播数据包转发给下游。出口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).
Threshold Infinity：一种PIM-SM过程，其中没有为沿共享树（*，G）转发的多播数据包创建源特定的多播（S，G）树。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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]定义以下不透明值TLV：传输IPv4源TLV、传输IPv6源TLV、传输VPNv4源TLV和传输VPNv6源TLV。每个这样的TLV的值字段被划分为若干子字段，其中一个包含IP源地址，另一个包含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]中定义）中使用通配符组的过程不在当前文档的范围内：传输IPv4 Bidir TLV、传输IPv6 Bidir TLV、传输VPNv4 Bidir TLV和传输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元素不透明值。
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
[RFC6826]和[RFC7246]均未指定接收源地址或组地址子字段中包含零的mLDP FEC元素不透明值的入口LSR的行为。然而，如果
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.
Ingress LSR支持[RFC6826]和/或[RFC7246]，但不支持本文件，因此它别无选择，只能将任何此类接收到的FEC元素视为无效；当不透明值在源地址或组地址子字段中包含零时，[RFC6826]和[RFC7246]中指定的过程不起作用。
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.
因此，本文档的过程假设，如果出口LSR在设置MP-LSP时使用通配符编码，则入口LSR（即多点LSP的根）支持本文档的过程。出口LSR在设置特定多点LSP时不得使用通配符编码，除非事先知道入口LSR支持本文档中的过程。如何知道这一点超出了本文件的范围。
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
PIM[RFC4601]具有“共享树”的概念，标识为（*，G）。仅当G是不在SSM地址范围内的IP多播组地址（即ASM组地址）时，此概念才适用。每个ASM组都与一个集合点（RP）关联，并且（*，G）树是朝着RP构建的（即，其根是RP）。G组的RP负责转发
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.
数据包沿着（*，G）树向下移动。沿着（*，G）树转发的数据包可以来自任何多播源，只要它们的IP目的地地址为G。
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了解给定组的所有多播源，然后加入每个此类源的源特定树。也就是说，当RP for G得知S有多播数据要发送给G时，RP加入（S，G）树。当RP从目的地为G的S接收多播数据时，RP沿（*，G）树转发数据。RP可以通过几种不同的方式了解给定群体的来源。RP可以通过PIM注册消息[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接收器的PIM路由器（称为G的“最后一跳”路由器）将首先加入（*，G）树。当它在（*，G）树上接收多播流量时，它（通过检查多播数据包的IP报头）学习正在向G发送的源。通常，当G组的最后一跳路由器学习到源S正在向G发送时，最后一跳路由器加入（S，G）树并“修剪”（*，G）树上的源。这允许每个最后一跳路由器沿从源到最后一跳路由器的最短路径接收多播数据。（有关此行为的详细信息，请参见[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路由域，并且希望使用mLDP而不是PIM通过该域建立“树”。
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域中，mLDP将用于构建MP-LSP，但这对发送方和接收方是隐藏的。[RFC4605]中定义的程序适用，因为发送方和接收方被认为彼此相距一跳。
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进行源发现。根据接收到的通配符，入口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:
使用mLDP带内信令的决定由出口LSR的IP多播组件根据所提供的策略作出。在mLDP不透明值TLV的IP源地址子字段中使用（或不使用）通配符的决定也是由IP多播组件根据配置的策略做出的。以下是一些可能有用的示例策略：
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.
1. 假设启用了PIM，出口LSR需要加入非双向ASM组G，并且G的RP可以通过BGP路由到达。出口LSR可以选择到RP的路由的BGP下一跳作为对应于（*，G）树的MP-LSP的入口LSR（根节点）（也参见第7节）。出口LSR可通过使用其IP源地址子字段包含通配符且其IP组地址子字段包含G的mLDP不透明值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. 假设组G未启用PIM，并且出口LSR已接收到G的IGMP/MLD组成员报告。出口LSR可确定G的“代理设备”（见第4.2节）。然后，它可以设置一个MP-LSP，其代理设备是入口LSR。出口LSR需要向入口LSR发送MP-LSP将承载属于G组的业务的信号；它通过使用不透明值TLV来实现这一点，该值的IP源地址子字段包含通配符，IP组地址子字段包含G。
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:
当入口LSR接收到为带内信令定义的mLDP不透明值TLV时，来自该TLV的子字段的信息被传递到入口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已经接收到所有必要的通信量。入口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应通过不透明值TLV标识的MP-LSP将（*，G）数据包转发给出口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不透明值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.
当入口LSR（即MP-LSP的根节点）接收到为带内信令定义的mLDP不透明值TLV时，来自该TLV的子字段的信息被传递到入口LSR的IP多播组件。如果IP组地址子字段包含通配符，则入口LSR检查其IP多播路由表，以查找其IP源地址为TLV的IP源地址子字段中指定地址的所有IP多播流。所有这些流都应该沿着不透明值TLV标识的MP-LSP向下转发。请注意，其中一些流可能具有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地址。为了遵循本文档的过程，有必要确定与给定（*，G）组IP多播流相对应的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，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年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组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，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）表上下文中的带内多点标签分发协议”，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.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播呈现点（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，“多播源发现协议（MSDP）”，RFC3618，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，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年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，“MPLS/BGP IP VPN中的多播”，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（编辑）思科系统公司De kleetlaan 6a Diegem 1831比利时
EMail: ice@cisco.com
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号01886
EMail: erosen@juniper.net
EMail: erosen@juniper.net
Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States
阿卡迪·古尔科·汤姆森路透社195美国纽约州纽约百老汇10007
EMail: arkadiy.gulko@thomsonreuters.com
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德国
EMail: Uwe.Joorde@telekom.de
EMail: Uwe.Joorde@telekom.de
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States
Jeff Tantsura Ericsson美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: jeff.tantsura@ericsson.com
EMail: jeff.tantsura@ericsson.com