Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6826 T. Eckert
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
M. Napierala
AT&T Labs
January 2013
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6826 T. Eckert
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
M. Napierala
AT&T Labs
January 2013
Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
用于点对多点和多点对多点标签交换路径的多点LDP带内信令
Abstract
摘要
Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs.
考虑IP组播树，它由协议无关组播（PIM）构建，需要通过MPLS域，其中多点LDP（MLDP）指向多点和/或多点到多点标签交换路径（LSP）。IP多播树中穿越MPLS域的部分可以实例化为多点LSP。当在MPLS域的边界接收到PIM加入消息时，来自该消息的信息被编码到mLDP消息中。当mLDP消息到达下一个IP域的边界时，编码信息用于生成可通过IP域发送的PIM消息。结果是IP多播树由一组IP多播子树组成，这些子树与多点LSP拼接在一起。本文档描述了如何将IP多播树与多点LSP拼接在一起的过程。
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/rfc6826.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6826.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6
2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6
2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7
3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6
2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6
2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7
3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
The mLDP (Multipoint LDP) [RFC6388] specification describes mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are typically used for transporting end-user multicast packets. However, the mLDP specification does not provide any rules for associating particular end-user multicast packets with any particular LSP. Other documents, like [RFC6513], describe applications in which out-of-band signaling protocols, such as PIM and BGP, are used to establish the mapping between an LSP and the multicast packets that need to be forwarded over the LSP.
mLDP（多点LDP）[RFC6388]规范描述了创建点对多点（P2MP）和多点对多点（MP2MP）LSP（标签交换路径）的机制。这些LSP通常用于传输最终用户多播数据包。然而，mLDP规范没有提供将特定最终用户多播分组与任何特定LSP相关联的任何规则。其他文档，如[RFC6513]，描述了使用带外信令协议（如PIM和BGP）在LSP和需要通过LSP转发的多播数据包之间建立映射的应用。
This document describes an application in which the information needed to establish the mapping between an LSP and the set of multicast packets to be forwarded over it is carried in the "opaque value" field of an mLDP FEC (Forwarding Equivalence Class) element. When an IP multicast tree (either a source-specific tree or a bidirectional tree) enters the MPLS network, the (S,G) or (*,G) information from the IP multicast control-plane state is carried in the opaque value field of the mLDP FEC message. As the tree leaves the MPLS network, this information is extracted from the FEC Element and used to build the IP multicast control plane. PIM messages can be sent outside the MPLS domain. Note that although the PIM control messages are sent periodically, the mLDP messages are not.
本文档描述了一种应用程序，其中在mLDP FEC（转发等价类）元素的“不透明值”字段中携带了在LSP和要在其上转发的多播分组集之间建立映射所需的信息。当IP多播树（源特定树或双向树）进入MPLS网络时，来自IP多播控制平面状态的（S，G）或（*，G）信息携带在mLDP FEC消息的不透明值字段中。当树离开MPLS网络时，该信息从FEC元素中提取并用于构建IP多播控制平面。PIM消息可以在MPLS域之外发送。请注意，尽管PIM控制消息会定期发送，但mLDP消息不会定期发送。
Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in the MPLS network. A network operator should expect to see as many LSPs in the MPLS network as there are IP multicast trees. A network operator should be aware how IP multicast state is created in the network to ensure that it does not exceed the scalability numbers of the protocol, either PIM or mLDP.
每个IP多播树都一一映射到MPLS网络中的P2MP或MP2MP LSP。网络运营商应该期望在MPLS网络中看到与IP多播树一样多的LSP。网络运营商应了解如何在网络中创建IP多播状态，以确保其不超过协议（PIM或mLDP）的可伸缩性编号。
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]中所述进行解释。
ASM: PIM Any Source Multicast
ASM:PIM任意源多播
Egress LSR: One of potentially many destinations of an LSP; also referred to as leaf node in the case of P2MP and MP2MP LSPs.
出口LSR：LSP的潜在多个目的地之一；在P2MP和MP2MP LSP的情况下也称为叶节点。
In-band signaling: Using the opaque value of an mLDP FEC Element to carry the (S,G) or (*,G) identifying a particular IP multicast tree.
带内信令：使用mLDP FEC元素的不透明值来携带识别特定IP多播树的（S，G）或（*，G）。
Ingress LSR: Source of the P2MP LSP; also referred to as a root node.
入口LSR：P2MP LSP的来源；也称为根节点。
IP multicast tree: An IP multicast distribution tree identified by an IP multicast Group address and, optionally, by a Source IP address, also referred to as (S,G) and (*,G).
IP多播树：由IP多播组地址和源IP地址（可选）标识的IP多播分发树，也称为（S，G）和（*，G）。
LSR: Label Switching Router
标签交换路由器
LSP: Labels Switched Path
标签交换路径
mLDP: Multipoint LDP
多点LDP
MP2MP LSP: An LSP that connects a set of leaf nodes that may each independently act as ingress or egress.
MP2MP LSP：连接一组叶节点的LSP，每个叶节点可独立充当入口或出口。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：多点LSP，P2MP或MP2MP LSP。
P2MP LSP: An LSP that has one Ingress Label Switching Router (LSR) and one or more Egress LSRs.
P2MP LSP：具有一个入口标签交换路由器（LSR）和一个或多个出口LSR的LSP。
RP: PIM Rendezvous Point
RP:PIM会合点
SSM: PIM Source-Specific Multicast
SSM:PIM源特定多播
Transit LSP: A P2MP or MP2MP LSP whose FEC Element contains the (S,G) or (*,G) identifying a particular IP multicast distribution tree.
传输LSP：一种P2MP或MP2MP LSP，其FEC元素包含标识特定IP多播分发树的（S，G）或（*，G）。
Transit LSR: An LSR that has one or more directly connected downstream LSRs.
运输LSR：具有一个或多个直接连接的下游LSR的LSR。
Consider the following topology:
考虑下面的拓扑结构：
|--- IPM ---|--- MPLS --|--- IPM ---|
|--- IPM ---|--- MPLS --|--- IPM ---|
S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
Figure 1
图1
Nodes A and B are IP-multicast-capable routers and connect to a Source/RP and a Receiver, respectively. Nodes U, C, and D are MPLS Label Switched Routers (LSRs).
节点A和B是支持IP多播的路由器，分别连接到源/RP和接收器。节点U、C和D是MPLS标签交换路由器（LSR）。
LSR D is attached to a network that is capable of MPLS multicast and IP multicast (see figure 1), and D is required to create a IP multicast tree due to a certain IP multicast event, like a PIM Join, MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-discovery route [SM-MLDP], or Rendezvous Point (RP) discovery. Suppose that D can determine that the IP multicast tree needs to travel through the MPLS network until it reaches LSR U. For instance, when D looks up the route to the Source or RP [RFC4601] of the IP multicast tree, it may discover that the route is a BGP route with U as the BGP next hop. Then D may choose to set up a P2MP or an MP2MP LSP, with U as root, and to make that LSP become part of the IP multicast distribution tree. Note that other methods are possible to determine that an IP multicast tree is to be transported across an MPLS network using P2MP or MP2MP LSPs. However, these methods are outside the scope of this document.
LSR D连接到能够进行MPLS多播和IP多播的网络（见图1），并且由于特定IP多播事件，如PIM加入、MSDP源公告（SA）[RFC3618]、BGP源主动自动发现路由[SM-MLDP]或集合点（RP）发现，需要LSR D创建IP多播树。假设D可以确定IP多播树需要穿过MPLS网络，直到它到达LSR U。例如，当D查找到IP多播树的源或RP[RFC4601]的路由时，它可能会发现该路由是一个BGP路由，U作为BGP下一跳。然后D可以选择建立一个P2MP或MP2MP LSP，U作为根，并使该LSP成为IP多播分发树的一部分。注意，可以使用其他方法来确定使用P2MP或MP2MP lsp在MPLS网络上传输IP多播树。但是，这些方法不在本文件的范围内。
In order to establish a multicast tree via a P2MP or MP2MP LSP using "in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with the IP address of LSR U as the "Root Node Address" and with the source and the group encoded into the "opaque value" ([RFC6388], Sections 2.2 and 3.2). Several different opaque value types are defined in this document. LSR D MUST NOT use a particular opaque value type unless it knows (through provisioning or through some other means outside the scope of this document) that LSR U supports the root node procedures for that opaque value type.
为了使用“带内信令”通过P2MP或MP2MP LSP建立多播树，LSR D编码P2MP或MP2MP FEC元素，LSR U的IP地址作为“根节点地址”，源和组编码为“不透明值”（[RFC6388]，第2.2和3.2节）。本文档中定义了几种不同的不透明值类型。LSR D不得使用特定的不透明值类型，除非它知道（通过设置或通过本文档范围之外的其他方式）LSR U支持该不透明值类型的根节点过程。
The particular type of FEC Element and opaque value used depends on the IP address family being used, and on whether the multicast tree being established is a source-specific or a bidirectional multicast tree.
所使用的特定类型的FEC元素和不透明值取决于所使用的IP地址族，以及所建立的多播树是源特定的还是双向多播树。
When an LSR receives a label mapping or withdraw whose FEC Element contains one of the opaque value types defined in this document, and that LSR is not the one identified by the "Root Node Address" field of that FEC Element, the LSR follows the procedures provided in RFC 6388.
当LSR接收到标签映射或撤销，其FEC元素包含本文档中定义的不透明值类型之一，并且LSR不是由该FEC元素的“根节点地址”字段标识的LSR时，LSR遵循RFC 6388中提供的过程。
When an LSR receives a label mapping or withdraw whose FEC Element contains one of the opaque value types defined in this document, and that LSR is the one identified by the Root Node Address field of that FEC Element, then the following procedure is executed. The multicast source and group are extracted and passed to the multicast code. If a label mapping is being processed, the multicast code will add the downstream LDP neighbor to the olist of the corresponding (S,G) or
当LSR收到标签映射或撤销，其FEC元素包含本文档中定义的不透明值类型之一，并且LSR是由该FEC元素的根节点地址字段标识的，则执行以下过程。多播源和组被提取并传递给多播代码。如果正在处理标签映射，则多播代码将下游LDP邻居添加到相应（S，G）或（S）的olist
(*,G) state, creating such state if it does not already exist. If a label withdraw is being processed, the multicast code will remove the downstream LDP neighbor from the olist of the corresponding (S,G) or (*,G) state. From this point on, normal PIM processing will occur.
（*，G）状态，如果该状态不存在，则创建该状态。如果正在处理标签撤回，则多播代码将从相应（S，G）或（*，G）状态的olist中移除下游LDP邻居。从这一点开始，将进行正常的PIM处理。
Note that if the LSR identified by the Root Node Address field does not recognize the opaque value type, the MP LSP will be established, but the root node will not send any multicast data packets on it.
注意，如果根节点地址字段标识的LSR不识别不透明值类型，则将建立MP LSP，但根节点不会在其上发送任何多播数据包。
Source or RP addresses that are reachable in a VPN context are outside the scope of this document.
在VPN上下文中可访问的源地址或RP地址不在本文档的范围内。
Multicast groups that operate in PIM Dense-Mode are outside the scope of this document.
在PIM密集模式下运行的多播组不在本文档的范围内。
Nothing prevents PIM shared trees, used by PIM-SM in the ASM service model, from being transported across an MPLS core. However, it is not possible to prune individual sources from the shared tree without the use of an additional out-of-band signaling protocol, like PIM or BGP [SM-MLDP]. For this reason, transiting shared trees across a transit LSP is outside the scope of this document.
在ASM服务模型中，PIM-SM使用的PIM共享树无法通过MPLS核心传输。然而，如果不使用额外的带外信令协议（如PIM或BGP[SM-MLDP]），就不可能从共享树中删除单个源。因此，在传输LSP上传输共享树超出了本文档的范围。
IP multicast source trees can be created via PIM operating in either SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM mode, the usual means of discovering active sources is to join a sparse-mode shared tree. However, this document does not provide any method of establishing a sparse-mode shared tree across an MPLS network. To apply the technique of this document to PIM-SM in ASM mode, there must be some other means of discovering the active sources. One possible means is the use of MSDP [RFC3618]. Another possible means is to use BGP Source Active auto-discovery routes, as documented in [SM-MLDP]. However, the method of discovering the active sources is outside the scope of this document; as a result, this document does not specify everything that is needed to support the ASM service model using in-band signaling.
IP多播源树可以通过在SSM模式[RFC4607]或ASM模式[RFC4601]下运行的PIM创建。在ASM模式下使用PIM-SM时，发现活动源的常用方法是加入稀疏模式共享树。但是，本文档不提供任何跨MPLS网络建立稀疏模式共享树的方法。要将本文档中的技术应用于ASM模式下的PIM-SM，必须有其他方法来发现活动源。一种可能的方法是使用MSDP[RFC3618]。另一种可能的方法是使用BGP源活动自动发现路由，如[SM-MLDP]中所述。但是，发现活动源的方法不在本文件的范围内；因此，本文档并未详细说明支持使用带内信令的ASM服务模型所需的一切。
The source and group addresses are encoded into the a transit TLV as specified in Sections 3.1 and 3.2.
按照第3.1节和第3.2节的规定，将源地址和组地址编码到传输TLV中。
If a bidirectional IP multicast tree [RFC5015] has to be transported over an MPLS network using in-band signaling, as described in this document, it MUST be transported using an MP2MP LSPs. A bidirectional tree does not have a specific source address; the group address, subnet mask, and RP are relevant for multicast forwarding. This document does not provide procedures to discover RP-to-group mappings dynamically across an MPLS network and assumes the RP is statically defined. Support of dynamic RP mappings in combination with in-band signaling is outside the scope of this document.
如本文件所述，如果双向IP多播树[RFC5015]必须使用带内信令通过MPLS网络传输，则必须使用MP2MP LSP传输。双向树没有特定的源地址；组地址、子网掩码和RP与多播转发相关。本文档不提供跨MPLS网络动态发现RP到组映射的过程，并假设RP是静态定义的。结合带内信令支持动态RP映射不在本文件范围内。
The RP for the group is used to select the ingress LSR and the root of the LSP. The group address is encoded according to the rules of Sections 3.3 or 3.4, depending on the IP version. The subnet mask associated with the bidirectional group is encoded in the Transit TLV. There are two types of bidirectional states in IP multicast, the group specific state and the RP state. The first type is typically created when a PIM Join has been received and has a subnet mask of 32 for IPv4 and 128 for IPv6. The RP state is typically created via the static RP mapping and has a variable subnet mask. The RP state is used to build a tree to the RP and is used for sender-only branches. Each state (group specific and RP state) will result in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be done by PIM on the root LSR. No special procedures are necessary for PIM to merge the two LSPs. Each LSP is effectively treated as a PIM-enabled interface. Please see [RFC5015] for more details.
组的RP用于选择入口LSR和LSP的根。根据IP版本，根据第3.3节或第3.4节的规则对组地址进行编码。与双向组关联的子网掩码在传输TLV中编码。IP多播中有两种类型的双向状态，组特定状态和RP状态。第一种类型通常是在收到PIM连接时创建的，对于IPv4，子网掩码为32，对于IPv6，子网掩码为128。RP状态通常通过静态RP映射创建，并且具有可变子网掩码。RP状态用于为RP构建树，并且仅用于发送方分支。每个状态（特定于组和RP状态）将产生单独的MP2MP LSP。两个MP2MP LSP的合并将由PIM在根LSR上完成。PIM合并两个LSP无需特殊程序。每个LSP都被有效地视为支持PIM的接口。有关更多详细信息，请参阅[RFC5015]。
For transporting the packets of a sender-only branch, we create a MP2MP LSP. Other sender-only branches will receive these packets and will not forward them because there are no receivers. These packets will be dropped. If that effect is undesirable, some other means of transport has to be established to forward packets to the root of the tree, for example, a multipoint-to-point LSP for example. A technique to unicast packets to the root of a P2MP or MP2MP LSP is documented in Section 3.2.2.1 of [MVPN-MSPMSI].
为了传输仅发送方分支的数据包，我们创建了一个MP2MP LSP。其他仅发送方分支将接收这些数据包，并且不会转发它们，因为没有接收方。这些数据包将被丢弃。如果该效果不理想，则必须建立一些其他传输方式以将分组转发到树的根，例如，多点对点LSP。[MVPN-MSPMSI]第3.2.2.1节记录了将数据包单播到P2MP或MP2MP LSP根的技术。
This section documents the different transit opaque encodings.
本节记录了不同的运输不透明编码。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3
类型：3
Length: 8 (octet size of Source and Group fields)
长度：8（源字段和组字段的八位字节大小）
Source: IPv4 multicast source address, 4 octets
来源：IPv4多播源地址，4个八位字节
Group: IPv4 multicast group address, 4 octets
组：IPv4多播组地址，4个八位字节
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4
类型：4
Length: 32 (octet size of Source and Group fields)
长度：32（源字段和组字段的八位字节大小）
Source: IPv6 multicast source address, 16 octets
来源：IPv6多播源地址，16个八位字节
Group: IPv6 multicast group address, 16 octets.
组：IPv6多播组地址，16个八位字节。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5
类型：5
Length: 9 (octet size of Mask Len, RP, and Group fields)
长度：9（掩码Len、RP和Group字段的八位字节大小）
Mask Len: The number of contiguous one bits that are left-justified and used as a mask, 1 octet. Maximum value allowed is 32.
掩码Len：左对齐并用作掩码的连续一位数，1个八位组。允许的最大值为32。
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个八位字节。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6
类型：6
Length: 33 (octet size of Mask Len, RP and Group fields)
长度：33（掩码Len、RP和Group字段的八位字节大小）
Mask Len: The number of contiguous one bits that are left-justified and used as a mask, 1 octet. Maximum value allowed is 128.
掩码Len：左对齐并用作掩码的连续一位数，1个八位组。允许的最大值为128。
RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 octets.
RP：集合点（RP）用于编码组的IPv6地址，16个八位字节。
Group: IPv6 multicast group address, 16 octets.
组：IPv6多播组地址，16个八位字节。
The same security considerations apply as for the base LDP specification, as described in [RFC5036].
与[RFC5036]中所述的基本LDP规范相同的安全注意事项也适用。
IANA has allocated the following values from the "LDP MP Opaque Value Element basic type" registry: are:
IANA已从“LDP MP不透明值元素基本类型”注册表中分配了以下值：
Transit IPv4 Source TLV type - 3
传输IPv4源TLV类型-3
Transit IPv6 Source TLV type - 4
传输IPv6源TLV类型-4
Transit IPv4 Bidir TLV type - 5
传输IPv4 Bidir TLV类型-5
Transit IPv6 Bidir TLV type - 6
传输IPv6 Bidir TLV类型-6
[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月。
[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月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[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月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
[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月。
[SM-MLDP] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Work in Progress, August 2011.
[SM-MLDP]Rekhter，Y.，Aggarwal，R.，和N.Leymann，“通过P2MP MLDP LSP在ASM模式树中承载PIM-SM”，正在进行的工作，2011年8月。
[MVPN-MSPMSI] Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers, MVPN: Optimized use of PIM via MS-PMSIs", February 2012.
[MVPN-MSPMSI]Cai，Y.，Rosen，E.，Ed.，Napierala，M.，和A.Boers，MVPN：通过MS PMSIs优化使用PIM”，2012年2月。
Thanks to Eric Rosen for his valuable comments on this document. Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa Andersson and Arkadiy Gulko for providing comments on this document.
感谢Eric Rosen对本文件的宝贵意见。还要感谢亚科夫·雷克特、阿德里安·法雷尔、尤维·乔尔德、洛亚·安德森和阿尔卡迪·古尔科对本文件的评论。
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
Toerless Eckert Cisco Systems, Inc. 170 Tasman Drive San Jose CA, 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134
EMail: eckert@cisco.com
EMail: eckert@cisco.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany
Nicolai Leymann德国电信公司Winterfeldtstrasse 21柏林10781德国
EMail: n.leymann@telekom.de
EMail: n.leymann@telekom.de
Maria Napierala AT&T Labs 200 Laurel Avenue Middletown NJ 07748 USA
Maria Napierala AT&T实验室美国新泽西州劳雷尔大道200号米德尔顿07748
EMail: mnapierala@att.com
EMail: mnapierala@att.com