RFC7438：Multipoint LDP (mLDP) In-Band Signaling with Wildcards，January 2015
梗概
存在IP组播树穿越MPLS域的场景。在这些情况下，当 IP 组播树进入 MPLS 域时，需要将其“无缝”转换为 MPLS 多点标签交换路径 (Multipoint Label Switched Path，MP-LSP)，然后在退出时将其转换回 IP 组播树MPLS域。以前的文件规定了允许将特定种类的 IP 组播树（源特定组播树或双向组播树）附加到 MPLS 多点标签交换路径 (MP-LSP) 的过程。然而，之前的文档没有指定将 IP Any-Source Multicast 树附加到 MP-LSP 的过程，也没有指定将多个 IP 组播树聚合到单个 MP-LSP 的过程。本文档规定了支持这些功能的程序。它通过定义“通配符”编码来实现，当建立 MP-LSP 时，可以指定一组 IP 组播树或共享 IP 组播树应该附加到该 MP-LSP。对非双向 IP 任意源组播树的支持受本文档中讨论的某些适用性限制的约束。本文档更新了 RFC 6826 和 7246。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7438。
版权声明
版权所有 (c) 2015 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
1、 简介
[RFC6826] 和 [RFC7246] 为 mLDP（Multipoint LDP，多点 LDP）指定了允许 IP 组播树（源特定组播树或双向组播树）“无缝”连接到 MPLS 多点标签交换路径（MP-LSP）。例如，当存在源自支持 IP 组播的域中的组播数据，然后必须在支持 MPLS 组播的域中转发，然后必须在另一个支持 IP 组播的域中转发时，这可能很有用。通过将 IP 组播树附加到 MP-LSP，沿 IP 组播树传播的数据在进入 MPLS 组播域时可以无缝地移动到 MP-LSP。然后数据沿着 MP-LSP 穿过 MPLS 域。当数据到达 MPLS 域的边界时，可以无缝地移动到 IP 组播树上。这种将 IP 组播树附加到 MPLS MP-LSP 的能力在 VPN 上下文或全局上下文中都很有用。
在 mLDP 中，每个 MP-LSP 由“根节点”（或“入口标签交换路由器 (Label Switching Router，LSR)”）和“不透明值”的组合标识，在根节点的上下文中，该值唯一标识 MP -LSP。这些被编码到 mLDP“转发等效类 (Forwarding Equivalence Class，FEC) 元素”中。为了建立 MP-LSP，Egress LSR 发起包含 FEC 元素的 mLDP 控制消息。给定的 FEC 元素值标识单个 MP-LSP，并从 Egress LSR 通过中间 LSR 向上游传递到 Ingress LSR。
在 IP 组播中，组播树由 IP 源地址（“S”）和 IP 组地址（“G”）的组合标识，通常写作“(S,G)”。承载多源流量的树由其组地址标识，标识写为“(*,G)”。
当建立 MP-LSP 时，[RFC6826] 和 [RFC7246] 的过程，称为“mLDP 带内信令”，允许 MP-LSP 的 Egress LSR 将 IP 组播树的标识符编码为标识 MP-LSP 的 mLDP FEC 元素的“不透明值”字段。只有 Egress 和 Ingress LSR 知道 mLDP FEC 元素包含 IP 组播树标识符的编码；MP-LSP的中间节点不考虑FEC Element的Opaque Value的内部结构，Opaque Value的内部结构不影响mLDP的运行。通过使用 mLDP 带内信令，MP-LSP 的 Egress LSR 通知 Ingress LSR 他们希望在 MP-LSP 上承载已识别 IP 组播树的流量（并且仅该流量）。也就是说，mLDP 带内信令不仅建立 MP-LSP，还将给定的 IP 组播树绑定到 MP-LSP。
如果在 VPN 上下文 [RFC7246] 中进行组播，则 mLDP FEC 元素还包含“路由区分符”（Route Distinguisher，RD）（参见 [RFC7246]），因为 IP 组播树不仅由“（S，G )”，但通过“（RD，S，G）”。本文件的程序也适用于这种情况。当然，当 Ingress LSR 处理包含 RD 的带内信令不透明值时，它会在与该 RD 关联的 VPN 的上下文中这样做。
如果不使用 mLDP 带内信令，则必须使用其他协议将 IP 组播树绑定到 MP-LSP；这需要 MP-LSP 的 Ingress LSR 和 Egress LSR 之间的额外通信机制。mLDP 带内信令的目的是消除对这些其他协议的需求。
当遵循 [RFC6826] 和 [RFC7246] 的非双向树程序时，Opaque Value 有一个 IP 源地址 (S) 和一个 IP 组地址 (G) 编码在其中，从而使其能够识别特定的 IP 组播(S,G) 树。在给定的 FEC 元素中只能识别单个 IP 源特定的组播树（即单个“(S,G)”）。因此，给定的 MP-LSP 只能从单个 IP 源特定的组播树（即单个“（S，G）树”）携带数据。但是，在某些情况下，希望在单个 MP-LSP 上聚合多个 (S,G) 树。聚合允许给定数量的 IP 组播树使用较少数量的 MP-LSP，从而节省网络中的状态。
此外，[RFC6826] 和 [RFC7246] 不支持将 Any-Source Multicast (ASM) 共享树附加到 MP-LSP，除非 ASM 共享树是双向树（即树由 BIDIR-PIM [RFC5015] 设置）。但是，在某些情况下，希望将非双向 ASM 共享树附加到 MP-LSP。
本文档指定了一种对 mLDP“不透明值”进行编码的方法，其中“S”或“G”或两者都被“通配符”（写为“*”）替换。描述了使用通配符编码将非双向 ASM 共享树映射到 MP-LSP 以及将多个 (S,G) 树（具有 S 的公共值或 G 的公共值）映射到单个 MP-LSP 的过程.
通配符编码有用的一些示例场景是
* PIM 共享树转发与“阈值无穷大”；
* IGMP/组播侦听器发现 (MLD) 代理；和
* 选择性源映射。
这些场景将在第 4 节中讨论。请注意，此场景列表并非详尽无遗。
本文档仅指定特定于使用通配符的 mLDP 过程。不特定于使用通配符的 mLDP 带内信令过程可以在 [RFC6826] 和 [RFC7246] 中找到。除非本文档中另有规定，否则这些程序在使用通配符时仍然适用。
2、 术语和定义
假定本文档的读者熟悉作为规范性参考文献列出的文档的术语和概念。为方便起见，下面列出了一些更常用的术语。
IGMP
Internet Group Management Protocol，互联网组管理协议。
In-band signaling
带内信令，使用 mLDP FEC 元素的不透明值来携带 (S,G) 或 (*,G) 标识特定 IP 组播树。该文档还允许将 (S,*) 编码为不透明值；见第 6 节。
Ingress LSR
入口 LSR，MP-LSP的根节点。当使用 mLDP 带内信令时，Ingress LSR 从下游接收有关特定 MP-LSP 的 mLDP 消息，并在上游发出 IP 组播控制消息。向上游发出的 IP 组播控制消息集取决于 LDP 不透明值 TLV 的内容。Ingress LSR 还从上游接收 IP 组播数据消息，并将它们作为 MP-LSP 上的 MPLS 数据包向下游发送。
IP multicast tree
IP组播树，由 IP 组播组地址和可选的源 IP 地址标识的 IP 组播分发树，也称为 (S,G) 和 (*,G)。
MLD
Multicast Listener Discovery，组播侦听器发现。
mLDP
Multipoint LDP，多点 LDP。
MP-LSP
点对多点 (Point-to-Multipoint，P2MP) 或多点对多点 (Multipoint-to-Multipoint，MP2MP) LSP。
PIM
Protocol Independent Multicast，协议无关组播。
PIM-ASM
PIM Any-Source Multicast，任意源组播。
PIM-SM
PIM Sparse Mode，稀疏模式。
PIM-SSM
PIM Source-Specific Multicast，源特定组播。
RP
PIM Rendezvous Point，集合点。
Egress LSR
出口 LSR，MP-LSP 的 Egress LSR 是从该 MP-LSP 上的上游接收 MPLS 组播数据包，并将该数据作为 IP 组播数据包转发到下游的 LSP。Egress LSR 还从下游接收 IP 组播控制消息，并在上游发送 mLDP 控制消息。当使用带内信令时，Egress LSR 根据从下游接收到的 IP 组播控制消息的内容，构建包含 IP 源和/或组地址的不透明值 TLV。
Threshold Infinity
阈值无穷大，一种 PIM-SM 过程，其中没有为沿共享树 (*,G) 转发的组播数据包创建特定源组播 (S,G) 树。
TLV
一个协议元素，由一个type类型字段、一个length长度字段和一个value值字段组成。请注意，TLV 的值字段可以细分为多个子字段。
关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选” " 本文档中的 " 将按照 RFC 2119 [RFC2119] 中的描述进行解释。
3、 mLDP 不透明值 TLV 中的通配符
[RFC6826] 和 [RFC7246] 定义了以下不透明值 TLV：Transit IPv4 Source TLV、Transit IPv6 Source TLV、Transit VPNv4 Source TLV 和 Transit VPNv6 Source TLV。每个这样的TLV的值字段被划分为多个子字段，其中一个包含IP源地址，一个包含IP组地址。根据这些文档，这些字段必须包含有效的 IP 地址。
本文档通过允许 IP 源地址字段或 IP 组地址字段（或两者）指定“通配符”而不是有效 IP 地址来扩展这些 TLV 的定义。
3.1、 编码通配符
IP 源地址子字段中的全零值用于表示通配符源地址。IP 组地址子字段中的全零值用于表示通配符组地址。请注意，这些子字段的长度在以前的文档中指定。
3.2、 通配符语义
如果 IP 源地址子字段包含通配符，并且 IP 组地址子字段包含不在 SSM 地址范围内的 IP 组播组地址（参见 [RFC4601] 的第 4.8 节），则 TLV 标识 PIM-SM 共享树。请参阅第 3.4 节了解适用于本案例的适用性限制。
如果 IP 源地址子字段包含通配符，并且 IP 组地址子字段包含在 SSM 地址范围内的 IP 组播组地址，则 TLV 标识具有给定组地址的 PIM 树的集合。
如果 IP 源地址子字段包含非零 IP 地址，并且 IP 组地址子字段包含通配符，则 TLV 标识以源地址为根的 PIM-SSM 树的集合。
第 4、5 和 6 节讨论了使用通配符的过程。请注意，与往常一样，不透明值 TLV 的结构不会影响 mLDP 的操作。该结构仅对 Ingress 和 Egress LSR 处的 IP 组播模块有意义。
在以下 TLV（在 [RFC6826] 或 [RFC7246] 中定义）中使用通配符组的程序超出了当前文档的范围：Transit IPv4 Bidir TLV、Transit IPv6 Bidir TLV、Transit VPNv4 Bidir TLV 和 Transit VPNv6 Bidir TLV。
在同一 TLV 中同时使用通配符源和通配符组的程序超出了当前文档的范围。
注意 Bidir TLV 没有源地址子字段，因此通配符源的概念不适用于它们。
3.3、 向后兼容性
本文档的过程不会改变 [RFC6826] 和 [RFC7246] 中描述的行为。
支持 [RFC6826] 和/或 [RFC7246] 但不支持本文档的正确操作的 Egress LSR 将永远不会生成包含源或组通配符的 mLDP FEC 元素不透明值。
[RFC6826] 和 [RFC7246] 都没有指定接收 mLDP FEC 元素不透明值的入口 LSR 的行为，这些值在源地址或组地址子字段中包含零。但是，如果 Ingress LSR 支持 [RFC6826] 和/或 [RFC7246]，但不支持此文档，则它别无选择，只能将任何此类接收到的 FEC 元素视为无效；当 Opaque 值在源地址或组地址子字段中包含零时，[RFC6826] 和 [RFC7246] 中指定的程序不起作用。
因此，本文档的程序假定如果 Egress LSR 在建立 MP-LSP 时使用通配符编码，则 Ingress LSR（即多点 LSP 的根）支持本文档的程序。一个 Egress LSR 在建立一个特定的多点 LSP 时不得使用通配符编码，除非事先知道该 Ingress LSR 支持本文档的过程。如何知道这一点超出了本文档的范围。
3.4、 ASM 的适用性限制
一般而言，对非双向 PIM-ASM 树的支持需要 (a) 确定给定 ASM 树的源集的过程（“源发现”），以及 (b) 将特定源从共享资源中剪除的过程树（“源修剪”）。本文档中未指定此类程序。因此，不得使用通配符源与 ASM 组地址的组合，除非事先知道既不需要源发现也不需要源修剪。如何知道这一点超出了本文档的范围。第 4 节描述了一些不需要源发现和源修剪的用例。
当然，有些用例需要源发现和/或源修剪。这些可以通过[RFC6513]、[RFC6514]和[GTM]中指定的过程来处理。对于这些情况，不建议使用 mLDP 带内信令。
4、 一些通配符用例
本节讨论了一些通配符用例。这里的用例集并不详尽。在每个用例中，Egress LSR 构造 mLDP 不透明值 TLV，其中包含 IP 源地址或 IP 组地址子字段中的通配符。
4.1、 PIM 共享树转发
PIM [RFC4601] 具有“共享树”的概念，标识为 (*,G)。此概念仅适用于 G 是不在 SSM 地址范围内的 IP 组播组地址（即，是 ASM 组地址）时。每个 ASM 组都与一个集合点 (RP) 相关联，并且 (*,G) 树是针对 RP 构建的（即，它的根是 RP）。组 G 的 RP 负责沿 (*,G) 树转发数据包。沿着 (*,G) 树转发的数据包可以来自任何组播源，只要它们的 IP 目标地址为 G。
RP 了解给定组的所有组播源，然后为每个此类源加入源特定树。也就是说，当 G 的 RP 得知 S 有组播数据要发送给 G 时，RP 加入（S，G）树。当 RP 从 S 接收到发往 G 的组播数据时，RP 将数据沿 (*,G) 树转发。RP 可以通过几种不同的方式了解给定组的来源。RP 可以通过 PIM 注册消息 [RFC4601]、组播源发现协议 (MSDP) [RFC3618] 或通过观察来自直接连接到 RP 的源的数据包来了解源。
在 PIM 中，具有特定 ASM 组播组 G 接收器的 PIM 路由器（称为 G 的“最后一跳”路由器）将首先加入 (*,G) 树。当它在 (*,G) 树上接收组播流量时，它会（通过检查组播数据包的 IP 报头）了解正在传输到 G 的源。通常，当组 G 的最后一跳路由器获知源 S正在向 G 传输，最后一跳路由器加入 (S,G) 树并从 (*,G) 树中“剪除” S。这允许每个最后一跳路由器沿从源到最后一跳路由器的最短路径接收组播数据。（此行为的完整细节可以在 [RFC4601] 中找到。）
然而，在某些情况下，组 G 的最后一跳路由器可能决定不加入源树，而是继续从 (*,G) 树接收 G 的所有流量。在这种情况下，我们说最后一跳路由器对组 G 具有“无限阈值”。这是 [RFC4601] 中记录的可选行为。“阈值无穷大”通常用于 RP 位于组 G 的组播源和组播接收者之间的部署中，即在已知从任何源到组的任何接收者的最短路径通过 RP 的部署中.在这些部署中，最后一跳路由器加入源树没有优势，因为数据已经沿着最短路径传输。执行加入源树和从共享树中剪除源的复杂过程的唯一效果是增加网络中必须维护的组播路由状态的数量。
为了在这种情况下有效地使用 mLDP 带内信令，Egress LSR 有必要构造一个标识 (*,G) 树的不透明值 TLV。这是通过在 IP 源地址子字段中使用通配符并将 IP 组地址子字段设置为 G 来完成的。
请注意，这些 mLDP 带内信令过程在不使用“阈值无穷大”的情况下不支持 PIM-ASM。
4.2、 IGMP/MLD 代理
在某些情况下，组播发送方和接收方直接连接到 MPLS 路由域，并且希望使用 mLDP 而不是 PIM 通过该域建立“树”。
在这些场景中，我们可以应用“IGMP/MLD 代理”并取消使用 PIM。发送者和接收者认为 MPLS 域是彼此之间的单跳。[RFC4605] 记录了不需要组播路由协议来构建“简单树”的过程。在 MPLS 域内，mLDP 将用于构建 MP-LSP，但这对发送者和接收者是隐藏的。[RFC4605] 中定义的过程是适用的，因为发送者和接收者被认为彼此相距一跳。
为了使 mLDP 构建必要的 MP-LSP，它需要知道树的根。按照 [RFC4605] 中定义的程序，我们依靠手动配置 ASM 组播组的 mLDP 根。由于给定 ASM 组播组的 MP-LSP 将携带来自该组所有源的流量，因此用于构造 MP-LSP 的不透明值 TLV 将在 IP 源地址子字段中包含通配符。
4.3、 选择性源映射
在许多 IPTV 部署中，内容服务器都集中在少数几个站点中。流行的通道通常是静态配置的，并通过核心 MPLS 网络转发到 Egress 路由器。由于这些通道是静态定义的，它们也可以通过带有通配符编码的多点 LSP 转发。需要使用的通配符编码类型（源和/或组）取决于 IPTV 提供商的源/组分配策略。其他选项是使用 MSDP [RFC3618] 或 BGP“自动发现”程序 [RFC6513] 由 Ingress LSR 进行源发现。根据接收到的通配符，Ingress LSR 可以从它具有状态的 IP 组播流集合中进行选择。
5、 通配符源使用程序
使用 mLDP 带内信令的决定是由 Egress LSR 的 IP 组播组件根据提供的策略做出的。在 mLDP 不透明值 TLV 的 IP 源地址子字段中使用（或不使用）通配符的决定也由 IP 组播组件做出，同样基于提供的策略。以下是一些可能有用的示例策略：
1. 假设PIM使能，Egress LSR需要加入一个非双向ASM组G，G的RP通过BGP路由可达。 Egress LSR 可以选择到 RP 的路由的 BGP Next Hop 作为与 (*,G) 树对应的 MP-LSP 的 Ingress LSR（根节点）（另见第 7 节）。Egress LSR可以通过一个mLDP Opaque Value TLV来识别（*，G）树，该TLV的IP源地址子字段包含通配符，其IP组地址子字段包含G。
2. 假设组 G 没有启用 PIM，并且 Egress LSR 已收到 G 的 IGMP/MLD 组成员报告。 Egress LSR 可以确定 G 的“代理设备”（参见第 4.2 节）。然后它可以建立一个MP-LSP，其代理设备是Ingress LSR。Egress LSR 需要向 Ingress LSR 发信号通知 MP-LSP 将承载属于 G 组的流量；它通过使用 IP 源地址子字段包含通配符且 IP 组地址子字段包含 G 的不透明值 TLV 来做到这一点。
由于任何一种部署中所需的策略可能与另一种部署中所需的策略大不相同，因此本文档未指定任何特定的策略集作为强制实施。
当 Ingress LSR 接收到已为带内信令定义的 mLDP Opaque Value TLV 时，来自该 TLV 子字段的信息被传递到 Ingress LSR 的 IP 组播组件。如果 IP 源地址子字段包含通配符，则 IP 组播组件必须确定如何处理它。处理必须遵循以下规则：
1. 如果启用了 PIM 并且在 Opaque Value TLV 中标识的组是非双向 ASM 组，则 Ingress LSR 的行为就像它从下游节点接收到 (*,G) IGMP/MLD 报告一样，并且程序遵循 [RFC4601] 中的定义。
2. 如果启用了 PIM 并且标识的组是 PIM-SSM 组，则 Ingress LSR 上该组已知的所有组播源都将沿 MP-LSP 转发。在这种情况下，假设 Ingress LSR 已经在接收所有必要的流量。Ingress LSR 如何接收此流量超出了本文档的范围。
3. 如果识别的组没有启用 PIM，Ingress LSR 就好像它从下游节点接收到 (*,G) IGMP/MLD 报告一样，并遵循 [RFC4605] 中定义的程序。Ingress LSR 应该通过 Opaque Value TLV 标识的 MP-LSP 将 (*,G) 数据包转发给 Egress LSR。（另见第 4.2 节。）
6、 通配符组使用程序
使用 mLDP 带内信令的决定是由 Egress LSR 的 IP 组播组件根据提供的策略做出的。在 mLDP 不透明值 TLV 的 IP 组地址子字段中使用（或不使用）通配符的决定也由 Egress LSR 的 IP 组播组件做出，同样基于提供的策略。由于任何一种部署中所需的策略可能与另一种部署中所需的策略大不相同，因此本文档未指定任何特定的策略集作为强制实施。
当 Ingress LSR（即 MP-LSP 的根节点）接收到已为带内信令定义的 mLDP Opaque Value TLV 时，来自该 TLV 子字段的信息被传递给 Ingress 的 IP 组播组件LSR。如果 IP 组地址子字段包含通配符，则 Ingress LSR 检查其 IP 组播路由表，以查找其 IP 源地址为 TLV 的 IP 源地址子字段中指定的地址的所有 IP 组播流。所有这些流都应该沿着由不透明值 TLV 标识的 MP-LSP 转发。请注意，其中一些流可能具有 SSM 组地址，而某些流可能具有 ASM 组地址。
7、 确定 MP-LSP 根（Ingress LSR）
[RFC6826] 和 [RFC7246] 描述了 Egress LSR 可以确定与给定 (S,G) IP 组播流相对应的 MP-LSP 根节点地址的过程。该确定基于组播流的源（“S”）的IP地址。为了遵循本文档的过程，有必要确定对应于给定 (*,G) 组 IP 组播流的 MP-LSP 根节点。与上述过程的唯一区别是使用代理设备或 RP 地址而不是源来发现 mLDP 根节点地址。
其他确定根节点的过程也是允许的，由策略决定。
8、 任播RP
在使用 mLDP 带内信令的场景中，RP 到组的映射不太可能在 MPLS 核心上动态分布。RP 地址更有可能是在每个组播站点静态配置的。在这些情况下，建议在每个站点配置一个 Anycast RP 地址以提供冗余。有关详细信息，请参阅 [RFC3446]。
9、 安全考虑
除了 [RFC5036]、[RFC6826] 和 [RFC7246] 中已经提到的安全考虑之外，没有其他安全考虑。
10、 参考文献
10.1、 规范性参考
[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>. [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>. [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>. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <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>. [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>.
10.2、 参考资料
[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. [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>. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003, <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>. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012, <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>.
致谢
我们要感谢 Loa Andersson、Pranjal Dutta、Lizhong Jin 和 Curtis Villamizar 的审阅和评论。
