Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7246 Cisco Systems
Category: Standards Track P. Hitchen
ISSN: 2070-1721 BT
N. Leymann
Deutsche Telekom
W. Henderickx
Alcatel-Lucent
A. Gulko
Thomson Reuters
J. Tantsura
Ericsson
June 2014
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7246 Cisco Systems
Category: Standards Track P. Hitchen
ISSN: 2070-1721 BT
N. Leymann
Deutsche Telekom
W. Henderickx
Alcatel-Lucent
A. Gulko
Thomson Reuters
J. Tantsura
Ericsson
June 2014
Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
虚拟路由和转发（VRF）表上下文中的带内多点标签分发协议
Abstract
摘要
An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.
IP多播分发树（MDT）可以遍历网络的标签交换（即，多协议标签交换，或MPLS）和非标签交换区域。通常，MDT在非MPLS区域开始和结束，但在MPLS区域中移动。在这种情况下，可以开始将MDT构建为纯IP MDT，然后在其进入MPLS启用区域时将其转换为MPLS多点标签交换路径（MP-LSP），然后在其进入非MPLS启用区域时将其转换回纯IP MDT。其他文件规定了构建这种混合MDT的过程，在网络的非MPLS区域使用协议独立多播（PIM），在MPLS区域使用多点标签分发协议（mLDP）。本文档扩展了这些过程，以处理连接两个区域的链路是虚拟路由和转发（VRF）表链路的情况，如“BGP IP/MPLS VPN”规范中所定义。然而，本文档主要针对VRF用于支持多播VPN以外的多播应用程序的特定用例。
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/rfc7246.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7246.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. VRF In-Band Signaling for MP LSPs . . . . . . . . . . . . . . 5
3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7
3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7
3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit VPNv4 Bidir TLV . . . . . . . . . . . . . . . . . 9
3.4. Transit VPNv6 Bidir TLV . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. VRF In-Band Signaling for MP LSPs . . . . . . . . . . . . . . 5
3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7
3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7
3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit VPNv4 Bidir TLV . . . . . . . . . . . . . . . . . 9
3.4. Transit VPNv6 Bidir TLV . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Sometimes an IP Multicast Distribution Tree (MDT) traverses both MPLS-enabled and non-MPLS-enabled regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends the procedures from [RFC6826] to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification [RFC6513]. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.
有时，IP多播分发树（MDT）会遍历网络中启用MPLS和未启用MPLS的区域。通常，MDT在非MPLS区域开始和结束，但在MPLS区域中移动。在这种情况下，可以开始将MDT构建为纯IP MDT，然后在其进入MPLS启用区域时将其转换为MPLS多点标签交换路径（LSP），然后在其进入非MPLS启用区域时将其转换回纯IP MDT。其他文件规定了构建这种混合MDT的过程，在网络的非MPLS区域使用协议独立多播（PIM），在MPLS区域使用多点标签分发协议（mLDP）。本文件扩展了[RFC6826]中的程序，以处理连接两个区域的链路为虚拟路由和转发（VRF）表链路的情况，如“BGP IP/MPLS VPN”规范[RFC6513]中所定义。然而，本文档主要针对VRF用于支持多播VPN以外的多播应用程序的特定用例。
In PIM, a tree is identified by a source address (or in the case of bidirectional trees [RFC5015], a rendezvous point address or "RPA") and a group address. The tree is built from the leaves up, by sending PIM control messages in the direction of the source address or the RPA. In mLDP, a tree is identified by a root address and an "opaque value", and is built by sending mLDP control messages in the direction of the root. The procedures of [RFC6826] explain how to convert a PIM <source address or RPA, group address> pair into an mLDP <root node, opaque value> pair and how to convert the mLDP <root node, opaque value> pair back into the original PIM <source address or RPA, group address> pair.
在PIM中，树由源地址（或在双向树[RFC5015]、集合点地址或“RPA”）和组地址标识。通过向源地址或RPA方向发送PIM控制消息，从叶子向上构建树。在mLDP中，树由根地址和“不透明值”标识，并通过向根方向发送mLDP控制消息来构建。[RFC6826]的过程解释了如何将PIM<源地址或RPA，组地址>对转换为mLDP<根节点，不透明值>对，以及如何将mLDP<根节点，不透明值>对转换回原始PIM<源地址或RPA，组地址>对。
However, the procedures in [RFC6826] assume that the routers doing the PIM/mLDP conversion have routes to the source address or RPA in their global routing tables. Thus, the procedures cannot be applied exactly as specified when the interfaces connecting the non-MPLS-enabled region to the MPLS-enabled region are interfaces that belong to a VRF as described in [RFC4364]. This specification extends the procedures of [RFC6826] so that they may be applied in the VRF context.
然而，[RFC6826]中的过程假设进行PIM/mLDP转换的路由器在其全局路由表中有到源地址或RPA的路由。因此，当连接非MPLS启用区域和MPLS启用区域的接口是属于[RFC4364]中所述VRF的接口时，不能完全按照规定应用程序。本规范扩展了[RFC6826]的程序，以便在VRF环境中应用。
As in [RFC6826], the scope of this document is limited to the case where the multicast content is distributed in the non-MPLS-enabled regions via PIM-created source-specific or bidirectional trees. Bidirectional trees are always mapped onto multipoint-to-multipoint LSPs, and source-specific trees are always mapped onto point-to-multipoint LSPs.
与[RFC6826]一样，本文档的范围仅限于通过PIM创建的源特定树或双向树将多播内容分布在未启用MPLS的区域的情况。双向树始终映射到多点对多点LSP，源特定树始终映射到点对多点LSP。
Note that the procedures described herein do not support non-bidirectional PIM Any-Source Multicast (ASM) groups, do not support the use of multicast trees other than mLDP multipoint LSPs in the core, and do not provide the capability to aggregate multiple PIM trees onto a single multipoint LSP. If any of those features are needed, they can be provided by the procedures of [RFC6513] and [RFC6514]. However, there are cases where multicast services are offered through interfaces associated with a VRF, and where mLDP is used in the core, but where aggregation is not desired. For example, some service providers offer multicast content to their customers, but have chosen to use VRFs to isolate the various customers and services. This is a simpler scenario than one in which the customers provide their own multicast content, out of the control of the service provider, and can be handled with a simpler solution. Also, when PIM trees are mapped one-to-one to multipoint LSPs, it is helpful for troubleshooting purposes to have the PIM source/group addresses encoded into the mLDP FEC (Forwarding Equivalence Class) element in what this document terms "mLDP in-band signaling".
注意，本文描述的过程不支持非双向PIM任何源多播（ASM）组，不支持在核心中使用mLDP多点LSP以外的多播树，并且不提供将多个PIM树聚合到单个多点LSP上的能力。如果需要这些特性中的任何一个，可以通过[RFC6513]和[RFC6514]的程序提供。然而，在某些情况下，通过与VRF相关联的接口提供多播服务，在核心中使用mLDP，但不需要聚合。例如，一些服务提供商向其客户提供多播内容，但选择使用VRF隔离各种客户和服务。这是一个比客户提供自己的多播内容（不受服务提供商的控制）更简单的场景，并且可以使用更简单的解决方案来处理。此外，当PIM树被一对一映射到多点LSP时，将PIM源/组地址编码到本文档所称的“mLDP带内信令”中的mLDP FEC（转发等价类）元素中有助于故障排除。
In order to use the mLDP in-band signaling procedures for a particular group address in the context of a particular set of VRFs, those VRFs MUST be configured with a range of multicast group addresses for which mLDP in-band signaling is to be enabled. This configuration is per VRF defined in [RFC4364]). For those groups, and those groups only, the procedures of this document are used. For other groups, the general-purpose multicast VPN procedures MAY be used, although it is more likely this VRF is dedicated to mLDP in-band signaling procedures and all other groups are discarded. The configuration MUST be present in all PE routers that attach to sites containing senders or receivers for the given set of group addresses. Note that because the provider most likely owns the multicast content and the method of transportation across the network, which are both transparent to the end user, no coordination needs to happen between the end user and the provider.
为了在特定VRF集合的上下文中对特定组地址使用mLDP带内信令过程，必须为这些VRF配置一系列要启用mLDP带内信令的多播组地址。此配置符合[RFC4364]中定义的VRF。对于这些组，以及仅针对这些组，使用本文件中的程序。对于其他组，可使用通用多播VPN过程，尽管更可能该VRF专用于mLDP带内信令过程，并且丢弃所有其他组。该配置必须存在于连接到包含给定组地址集的发送方或接收方的站点的所有PE路由器中。请注意，由于提供商最有可能拥有多播内容和跨网络传输的方法，这对最终用户都是透明的，因此最终用户和提供商之间不需要进行协调。
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]中所述进行解释。
In-band signaling: Using the opaque value of an mLDP FEC element to encode the (S,G) or (*,G) identifying a particular IP multicast tree.
带内信令：使用mLDP FEC元素的不透明值对标识特定IP多播树的（S，G）或（*，G）进行编码。
Ingress LSR: Source of a P2MP LSP, also referred to as root node.
入口LSR：P2MP LSP的源，也称为根节点。
IP multicast tree: An IP multicast distribution tree identified by a source IP address and/or IP multicast destination address, also referred to as (S,G) and (*,G).
IP多播树：由源IP地址和/或IP多播目标地址标识的IP多播分发树，也称为（S，G）和（*，G）。
mLDP: Multipoint LDP.
mLDP：多点LDP。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：多点LSP，P2MP或MP2MP LSP。
MP2MP LSP: An LSP that connects a set of leaf nodes, acting indifferently as ingress or egress (see [RFC6388]).
MP2MP LSP：连接一组叶节点的LSP，作为入口或出口（参见[RFC6388]）。
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs (see [RFC6388]).
P2MP LSP：具有一个入口LSR和一个或多个出口LSR的LSP（参见[RFC6388]）。
RPA: Rendezvous Point Address, the address that is used as the root of the distribution tree for a range of multicast groups.
RPA：集合点地址，用作一系列多播组的分发树根的地址。
RD: Route Distinguisher, an identifier that makes a route unique in the context of a VRF.
RD：路由识别器，使路由在VRF上下文中唯一的标识符。
UMH: Upstream Multicast Hop, the upstream router in that is in the path to reach the source of the multicast flow.
UMH：上行多播跃点，位于到达多播流源路径中的上行路由器。
VRF: Virtual Routing and Forwarding table.
VRF：虚拟路由和转发表。
Suppose that a PE router, PE1, receives a PIM Join(S,G) message over one of its interfaces that is associated with a VRF. Following the procedure of Section 5.1 of [RFC6513], PE1 determines the "upstream RD", the "upstream PE", and the "upstream multicast hop" (UMH) for the source address S.
假设PE路由器PE1通过其与VRF关联的一个接口接收PIM连接（S，G）消息。按照[RFC6513]第5.1节的程序，PE1确定源地址S的“上游RD”、“上游PE”和“上游多播跃点”（UMH）。
In order to transport the multicast tree via a multipoint (MP) LSP using VRF in-band signaling, an mLDP Label Mapping message is sent by PE1. This message will contain either a P2MP FEC or an MP2MP FEC (see [RFC6388]), depending upon whether the PIM tree being transported is a source-specific tree, or a bidirectional tree, respectively. The FEC contains a "root" and an "opaque value".
为了使用VRF带内信令通过多点（MP）LSP传输多播树，PE1发送mLDP标签映射消息。此消息将包含P2MP FEC或MP2MP FEC（请参见[RFC6388]），具体取决于传输的PIM树是源特定树还是双向树。FEC包含一个“根”和一个“不透明值”。
If the UMH and the upstream PE have the same IP address (i.e., the upstream PE is the UMH), then the root of the multipoint FEC is set to the IP address of the upstream PE. If, in the context of this VPN, (S,G) refers to a source-specific MDT, then the values of S, G, and the upstream RD are encoded into the opaque value. If, in the context of this VPN, G is a bidirectional group address, then S is replaced with the value of the RPA associated with G.
如果UMH和上游PE具有相同的IP地址（即，上游PE是UMH），则多点FEC的根被设置为上游PE的IP地址。如果在该VPN的上下文中，（S，G）指特定于源的MDT，则S，G和上游RD的值被编码到不透明值中。如果在该VPN的上下文中，G是一个双向组地址，则S将替换为与G关联的RPA的值。
The encoding details are specified in Section 3. Conceptually, the multipoint FEC can be thought of as an ordered pair: {root=<Upstream-PE>; opaque_value=<S or RPA , G, Upstream-RD>}. The mLDP Label Mapping message is then sent by PE1 on its LDP session to the "next hop" on the message's path to the upstream PE. The "next hop" is usually the directly connected next hop, but see [RFC7060] for cases in which the next hop is not directly connected.
第3节规定了编码细节。从概念上讲，多点FEC可以被视为一个有序对：{root=<Upstream PE>；opaque_value=<S或RPA，G，Upstream RD>}。然后，mLDP标签映射消息由PE1在其LDP会话上发送到消息路径上的“下一跳”到上游PE。“下一个跃点”通常是直接连接的下一个跃点，但有关下一个跃点未直接连接的情况，请参见[RFC7060]。
If the UMH and the upstream PE do not have the same IP address, the procedures of Section 2 of [RFC6512] should be applied. The root node of the multipoint FEC is set to the UMH. The recursive opaque value is then set as follows: the root node is set to the upstream PE, and the opaque value is set to the multipoint FEC described in the previous paragraph. That is, the multipoint FEC can be thought of as the following recursive ordered pair: {root=<UMH>; opaque_value=<root=Upstream-PE, opaque_value=<S or RPA, G, Upstream-RD>>}.
如果UMH和上游PE没有相同的IP地址，则应采用[RFC6512]第2节的程序。多点FEC的根节点设置为UMH。然后，递归不透明值设置如下：根节点设置为上游PE，不透明值设置为上一段中描述的多点FEC。也就是说，多点FEC可以被认为是以下递归有序对：{root=<UMH>；不透明_值=<root=上游PE，不透明_值=<S或RPA，G，上游RD>}。
The encoding of the multipoint FEC also specifies the "type" of PIM MDT being spliced onto the multipoint LSP. Four opaque encodings are defined in [RFC6826]: IPv4 source-specific tree, IPv6 source-specific tree, IPv4 bidirectional tree, and IPv6 bidirectional tree.
多点FEC的编码还指定拼接到多点LSP上的PIM MDT的“类型”。[RFC6826]中定义了四种不透明编码：IPv4源特定树、IPv6源特定树、IPv4双向树和IPv6双向树。
When a PE router receives an mLDP message with a P2MP or MP2MP FEC, where the PE router itself is the root node, and the opaque value is one of the types defined in Section 3, then it uses the RD encoded in the opaque value field to determine the VRF context. (This RD will be associated with one of the PEs VRFs.) Then, in the context of that VRF, the PE follows the procedure specified in section 2 of [RFC6826].
当PE路由器接收到带有P2MP或MP2MP FEC的mLDP消息时，其中PE路由器本身是根节点，并且不透明值是第3节中定义的类型之一，则它使用不透明值字段中编码的RD来确定VRF上下文。（该RD将与一个PEs VRF关联。）然后，在该VRF的上下文中，PE遵循[RFC6826]第2节中规定的程序。
This section documents the different transit opaque encodings.
本节记录了不同的运输不透明编码。
This opaque value type is used when transporting a source-specific mode multicast tree whose source and group addresses are IPv4 addresses.
此不透明值类型用于传输源和组地址为IPv4地址的源特定模式多播树。
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 | Source
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Source
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 250
类型：250
Length: 16
长度：16
Source: IPv4 multicast source address, 4 octets.
来源：IPv4多播源地址，4个八位字节。
Group: IPv4 multicast group address, 4 octets.
组：IPv4多播组地址，4个八位字节。
RD: Route Distinguisher, 8 octets.
RD：路径识别器，8个八位字节。
This opaque value type is used when transporting a source-specific mode multicast tree whose source and group addresses are IPv6 addresses.
此不透明值类型用于传输源和组地址为IPv6地址的源特定模式多播树。
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 | Source ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Source ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 251
类型：251
Length: 40
长度：40
Source: IPv6 multicast source address, 16 octets.
来源：IPv6多播源地址，16个八位字节。
Group: IPv6 multicast group address, 16 octets.
组：IPv6多播组地址，16个八位字节。
RD: Route Distinguisher, 8 octets.
RD：路径识别器，8个八位字节。
This opaque value type is used when transporting a bidirectional multicast tree whose group address is an IPv4 address. The RP address is also an IPv4 address in this case.
此不透明值类型用于传输组地址为IPv4地址的双向多播树。在这种情况下，RP地址也是IPv4地址。
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 | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 9
类型：9
Length: 17
长度：17
Mask Len: The number of contiguous one bits that are left justified and used as a mask, 1 octet.
掩码Len：左对齐并用作掩码的连续一位数，1个八位组。
RP: Rendezvous Point (RP) IPv4 address used for the encoded Group, 4 octets.
RP：集合点（RP）用于编码组的IPv4地址，4个八位字节。
Group: IPv4 multicast group address, 4 octets.
组：IPv4多播组地址，4个八位字节。
RD: Route Distinguisher, 8 octets.
RD：路径识别器，8个八位字节。
This opaque value type is used when transporting a bidirectional multicast tree whose group address is an IPv6 address. The RP address is also an IPv6 address in this case.
此不透明值类型用于传输组地址为IPv6地址的双向多播树。在这种情况下，RP地址也是IPv6地址。
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 | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10
类型：10
Length: 41
长度：41
Mask Len: The number of contiguous one bits that are left justified and used as a mask, 1 octet.
掩码Len：左对齐并用作掩码的连续一位数，1个八位组。
RP: Rendezvous Point (RP) IPv6 address used for the encoded group, 16 octets.
RP：用于编码组的集合点（RP）IPv6地址，16个八位字节。
Group: IPv6 multicast group address, 16 octets.
组：IPv6多播组地址，16个八位字节。
RD: Route Distinguisher, 8 octets.
RD：路径识别器，8个八位字节。
The same security considerations apply as for the base LDP specification, described in [RFC5036], and the base mLDP specification, described in [RFC6388].
与[RFC5036]中描述的基本LDP规范和[RFC6388]中描述的基本mLDP规范相同的安全注意事项也适用。
Operators MUST configure packet filters to ensure that the mechanism described in this memo does not cause non-global-scoped IPv6 multicast packets to be tunneled outside of their intended scope.
运营商必须配置数据包过滤器，以确保本备忘录中描述的机制不会导致非全局范围的IPv6多播数据包被隧道传输到其预期范围之外。
[RFC6388] defines a registry for the "LDP MP Opaque Value Element basic type". IANA has assigned four new code points in this registry:
[RFC6388]为“LDP MP不透明值元素基本类型”定义注册表。IANA在此注册表中分配了四个新代码点：
Transit VPNv4 Source TLV type - 250
运输VPNv4源TLV类型-250
Transit VPNv6 Source TLV type - 251
运输VPNv6源TLV类型-251
Transit VPNv4 Bidir TLV type - 9
运输VPNv4 Bidir TLV类型-9
Transit VPNv6 Bidir TLV type - 10
运输VPNv6 Bidir TLV类型-10
Thanks to Eric Rosen, Andy Green, Yakov Rekhter, and Eric Gray for their comments on the document.
感谢Eric Rosen、Andy Green、Yakov Rekhter和Eric Gray对文档的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[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.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[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.
[RFC6512]Wijnands，IJ.，Rosen，E.，Napierala，M.，和N.Leymann，“当主干没有到根的路由时使用多点LDP”，RFC 6512，2012年2月。
[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.
[RFC6826]Wijnands，IJ.，Ed.，Eckert，T.，Leymann，N.，和M.Napierala，“用于点对多点和多点对多点标签交换路径的多点LDP带内信令”，RFC 6826，2013年1月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月。
[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.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月。
[RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, November 2013.
[RFC7060]Napierala，M.，Rosen，E.，和IJ。Wijnands，“在目标LDP会话上使用LDP多点扩展”，RFC 70602013年11月。
Authors' Addresses
作者地址
IJsbrand Wijnands (editor) Cisco Systems De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijnands（编辑）Cisco Systems De kleetlaan 6a Diegem 1831比利时电子邮件：ice@cisco.com
Paul Hitchen BT BT Adastral Park Ipswich IP53RE United Kingdom EMail: paul.hitchen@bt.com
Paul Hitchen BT BT Adastral Park Ipswich IP53RE英国电子邮件：Paul。hitchen@bt.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 Copernicuslaan 50 Antwerp 2018 Belgium EMail: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucent Copernicuslaan 50安特卫普2018比利时电子邮件：Wim。henderickx@alcatel-朗讯网
Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States EMail: arkadiy.gulko@thomsonreuters.com
阿卡迪·古尔科·汤姆森路透社195纽约百老汇，纽约10007美国电子邮件：阿卡迪。gulko@thomsonreuters.com
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States EMail: jeff.tantsura@ericsson.com
Jeff Tantsura Ericsson加利福尼亚州圣何塞霍尔格大道300号，邮编95134美国电子邮件：Jeff。tantsura@ericsson.com