RFC7246：Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context，June 2014
梗概
IP 组播分发树 (Multicast Distribution Tree，MDT) 可以遍历网络的标签交换（即多协议标签交换或 MPLS）和非标签交换区域。通常，MDT 在非 MPLS 区域中开始和结束，但要通过 MPLS 区域。在这种情况下，开始将 MDT 构建为纯 IP MDT，然后在进入启用 MPLS 的区域时将其转换为 MPLS 多点标签交换路径 (Multipoint Label Switched Path，MP-LSP)，然后将其转换回纯 IP MDT 进入未启用 MPLS 的区域时。其他文件规定了构建这种混合 MDT 的过程，在网络的非 MPLS 区域中使用协议独立组播 (Protocol Independent Multicast，PIM)，在 MPLS 区域中使用多点标签分发协议 (Multipoint Label Distribution Protocol，mLDP)。本文档扩展了这些程序以处理连接两个区域的链路是虚拟路由和转发 (Virtual Routing and Forwarding，VRF) 表链路的情况，如“BGP IP/MPLS VPN”规范中所定义。然而，本文档主要针对 VRF 用于支持组播 VPN 以外的组播应用的特定用例。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7246。
版权声明
版权所有 (c) 2014 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
1、 简介
有时，IP 组播分发树 (MDT) 会遍历网络中启用 MPLS 的区域和未启用 MPLS 的区域。通常，MDT 在非 MPLS 区域中开始和结束，但要通过 MPLS 区域。在这种情况下，开始将 MDT 构建为纯 IP MDT，然后在进入启用 MPLS 的区域时将其转换为 MPLS 多点标签交换路径 (LSP)，然后将其转换回纯 IP进入未启用 MPLS 的区域时的 MDT。其他文件规定了构建这种混合 MDT 的过程，在网络的非 MPLS 区域中使用协议独立组播 (PIM)，在 MPLS 区域中使用多点标签分发协议 (mLDP)。本文档扩展了 [RFC6826] 中的程序，以处理连接两个区域的链路是虚拟路由和转发 (VRF) 表链路的情况，如“BGP IP/MPLS VPN”规范 [RFC6513] 中所定义。然而，本文档主要针对 VRF 用于支持组播 VPN 以外的组播应用的特定用例。
在 PIM 中，树由源地址（或在双向树 [RFC5015] 的情况下，集合点地址或“RPA”）和组地址来标识。通过在源地址或 RPA 的方向发送 PIM 控制消息，从叶子向上构建树。在 mLDP 中，树由根地址和“不透明值”标识，并通过向根方向发送 mLDP 控制消息来构建。[RFC6826] 的过程解释了如何将 PIM <source address or RPA, group address> 对转换为 mLDP <root node, opaque value> 对以及如何将 mLDP <root node, opaque value> 对转换回原始 PIM <源地址或 RPA，组地址> 对。
然而，[RFC6826] 中的过程假定进行 PIM/mLDP 转换的路由器在其全局路由表中具有到源地址或 RPA 的路由。因此，当将非 MPLS 启用区域连接到 MPLS 启用区域的接口是属于 [RFC4364] 中描述的 VRF 的接口时，这些过程不能完全按照指定的方式应用。本规范扩展了 [RFC6826] 的程序，以便它们可以在 VRF 上下文中应用。
与 [RFC6826] 中一样，本文档的范围仅限于通过 PIM 创建的源特定或双向树在非 MPLS 启用区域中分发组播内容的情况。双向树总是映射到多点到多点 LSP，源特定树总是映射到点到多点 LSP。
请注意，此处描述的过程不支持非双向 PIM 任意源组播 (Any-Source Multicast，ASM) 组，不支持在核心中使用除 mLDP 多点 LSP 之外的组播树，并且不提供聚合多个 PIM 树的能力到单个多点 LSP 上。如果需要这些特性中的任何一个，它们可以通过 [RFC6513] 和 [RFC6514] 的程序提供。但是，在某些情况下，组播服务是通过与 VRF 关联的接口提供的，并且 mLDP 用于核心，但不需要聚合。例如，一些服务提供商向他们的客户提供组播内容，但选择使用 VRF 来隔离各种客户和服务。与客户提供自己的组播内容、不受服务提供商控制的情况相比，这是一种更简单的情况，并且可以使用更简单的解决方案来处理。此外，当 PIM 树一对一映射到多点 LSP 时，将 PIM 源/组地址编码到 mLDP FEC（转发等效类）元素中（在本文档中称为“mLDP带内信号”。
为了在一组特定 VRF 的上下文中对特定组地址使用 mLDP 带内信令过程，必须为这些 VRF 配置一个组播组地址范围，为这些地址启用 mLDP 带内信令。此配置符合 [RFC4364] 中定义的 VRF）。对于那些组，并且仅这些组，使用本文档的程序。对于其他组，可以使用通用组播 VPN 程序，尽管这个 VRF 更有可能专用于 mLDP 带内信令程序并且所有其他组都被丢弃。该配置必须存在于所有连接到站点的 PE 路由器中，这些站点包含给定组地址集的发送者或接收者。请注意，由于提供商很可能拥有组播内容和跨网络传输的方法，这对最终用户都是透明的，因此最终用户和提供商之间不需要进行协调。
1.1、 本文档中使用的约定
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。
1.2、 术语
In-band signaling：带内信令，使用 mLDP FEC 元素的不透明值对标识特定 IP 组播树的 (S,G) 或 (*,G) 进行编码。
Ingress LSR：P2MP LSP 的来源，也称为根节点。
IP multicast tree：IP 组播树，由源 IP 地址和/或 IP 组播目标地址标识的 IP 组播分发树，也称为 (S,G) 和 (*,G)。
mLDP：多点 LDP。
MP LSP：多点 LSP，P2MP 或 MP2MP LSP。
MP2MP LSP：连接一组叶节点的 LSP，充当入口或出口（参见 [RFC6388]）。
P2MP LSP：具有一个 Ingress LSR 和一个或多个 Egress LSR 的 LSP（参见 [RFC6388]）。
RPA：Rendezvous Point Address，集合点地址，用作一系列组播组的分发树根的地址。
RD：Route Distinguisher，在 VRF 上下文中使路由唯一的标识符。
UMH：Upstream Multicast Hop，即在到达组播流源的路径中的上游路由器。
VRF：Virtual Routing and Forwarding table，虚拟路由和转发表。
2、 MP LSP 的 VRF 带内信令
假设 PE 路由器 PE1 通过其与 VRF 关联的接口之一接收 PIM Join(S,G) 消息。按照 [RFC6513] 的第 5.1 节的过程，PE1 确定源地址 S 的“上游 RD”、“上游 PE”和“上游组播跳”（upstream multicast hop，UMH）。
为了使用 VRF 带内信令通过多点 (MP) LSP 传输组播树，PE1 发送 mLDP 标签映射消息。该消息将包含一个 P2MP FEC 或一个 MP2MP FEC（参见 [RFC6388]），这取决于所传输的 PIM 树分别是源特定树还是双向树。FEC 包含一个“根”和一个“不透明值”。
如果 UMH 和上游 PE 的 IP 地址相同（即上游 PE 是 UMH），则多点 FEC 的根设置为上游 PE 的 IP 地址。如果在此 VPN 的上下文中，(S,G) 指的是特定于源的 MDT，则 S、G 和上游 RD 的值被编码为不透明值。如果在此 VPN 的上下文中，G 是双向组地址，则 S 将替换为与 G 关联的 RPA 的值。
编码细节在第 3 节中指定。从概念上讲，多点 FEC 可以被认为是一个有序对：{root=<Upstream-PE>; opaque_value=<S 或 RPA，G，上游-RD>}。然后，PE1 在其 LDP 会话上将 mLDP 标签映射消息发送到到上游 PE 的消息路径上的“下一跳”。“下一跳”通常是直接连接的下一跳，但请参阅 [RFC7060] 了解下一跳不直接连接的情况。
如果UMH 和上游PE 没有相同的IP 地址，则应采用[RFC6512]第2 节的程序。多点 FEC 的根节点设置为 UMH。然后递归的不透明值设置如下：根节点设置为上游PE，不透明值设置为上一段中描述的多点FEC。也就是说，多点 FEC 可以被认为是以下递归有序对：{root=<UMH>; opaque_value=<root=Upstream-PE, opaque_value=<S or RPA, G, Upstream-RD>>}。
多点 FEC 的编码还指定了拼接到多点 LSP 上的 PIM MDT 的“类型”。[RFC6826] 中定义了四种不透明编码：IPv4 源特定树、IPv6 源特定树、IPv4 双向树和 IPv6 双向树。
当 PE 路由器接收到带有 P2MP 或 MP2MP FEC 的 mLDP 消息时，其中 PE 路由器本身是根节点，并且 opaque value 是第 3 节中定义的类型之一，那么它使用 opaque value 字段中编码的 RD确定 VRF 上下文。（该 RD 将与 PE VRF 之一相关联。）然后，在该 VRF 的上下文中，PE 遵循 [RFC6826] 第 2 节中指定的过程。
3、 对 LDP MP FEC 的不透明值进行编码
本节记录了不同的传输不透明编码。
3.1、 中转 VPNv4 源 TLV
当传输源和组地址为 IPv4 地址的源特定模式组播树时使用此不透明值类型。
Type：类型，250
Length：长度，16
Source：IPv4 组播源地址，4 个八位字节。
Group：IPv4 组播组地址，4 个八位字节。
RD：Route Distinguisher，路由识别器，8 个八位字节。
3.2、 中转 VPNv6 源 TLV
当传输源和组地址为 IPv6 地址的源特定模式组播树时使用此不透明值类型。
Type：类型，251
Length：长度，40
Source：IPv6 组播源地址，16 个八位字节。
Group：IPv6 组播组地址，16 个八位字节。
RD：Route Distinguisher，路由识别器，8 个八位字节。
3.3、 中转 VPNv4 双向 TLV
在传输组地址为 IPv4 地址的双向组播树时使用此不透明值类型。在这种情况下，RP 地址也是 IPv4 地址。
Type：类型，9
Length：长度，17
Mask Len：左对齐并用作掩码的连续 1 位的数量，1 个八位字节。
RP：用于编码组的集合点 (Rendezvous Point，RP) IPv4 地址，4 个八位字节。
Group：IPv4 组播组地址，4 个八位字节。
RD：路由识别器，8 个八位字节。
3.4、 中转 VPNv6 双向 TLV
当传输组地址为 IPv6 地址的双向组播树时使用此不透明值类型。在这种情况下，RP 地址也是 IPv6 地址。
Type：类型，10
Length：长度，41
Mask Len：左对齐并用作掩码的连续 1 位的数量，1 个八位字节。
RP：用于编码组的集合点 (RP) IPv6 地址，16 个八位字节。
Group：IPv6 组播组地址，16 个八位字节。
RD：路由识别器，8 个八位字节。
4、 安全考虑
相同的安全考虑适用于 [RFC5036] 中描述的基本 LDP 规范和 [RFC6388] 中描述的基本 mLDP 规范。
操作者必须配置数据包过滤器以确保本备忘录中描述的机制不会导致非全局范围的 IPv6 组播数据包通过隧道超出其预期范围。
5、 IANA 考虑事项
[RFC6388]为“LDP MP 不透明值元素基本类型”定义了一个注册表。IANA 已在此注册表中分配了四个新代码点：
中转 VPNv4 源 TLV 类型：250 中转 VPNv6 源 TLV 类型：251 中转 VPNv4 双向 TLV 类型：9 中转 VPNv6 双向 TLV 类型：10
6、 致谢
感谢 Eric Rosen、Andy Green、Yakov Rekhter 和 Eric Gray 对文档的评论。
7、 参考文献
7.1、 规范性参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [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. [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012. [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.
7.2、 参考资料
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [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. [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, November 2013.
