Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 7441 Cisco Systems, Inc.
Updates: 6514 E. Rosen
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 U. Joorde
Deutsche Telekom
January 2015
Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 7441 Cisco Systems, Inc.
Updates: 6514 E. Rosen
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 U. Joorde
Deutsche Telekom
January 2015
Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes
在BGP MCAST-VPN路由的NLRI中编码多点LDP（mLDP）转发等价类（FEC）
Abstract
摘要
Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.
许多服务提供商向其客户提供“BGP/MPLS IP VPN”服务。现有的IETF标准规定了服务提供商使用的程序和协议，以便向在其VPN中具有IP单播和IP多播流量的客户提供此服务。还希望能够支持在其VPN中具有MPLS多播流量的客户。本文档规定了支持使用多点LDP（mLDP）作为MPLS多播通信控制协议的客户所需的过程和协议扩展。现有标准确实为使用mLDP的客户提供了一些支持，但仅在一系列限制性的情况下。本文档概括了现有的支持，包括客户使用mLDP的所有情况，没有任何限制。本文件更新了RFC 6514。
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/rfc7441.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7441.
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 ....................................................2
2. Why This Document is Needed .....................................3
3. Encoding an mLDP FEC in the MCAST-VPN NLRI ......................5
4. Wildcards .......................................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
Acknowledgments ...................................................10
Authors' Addresses ................................................10
1. Introduction ....................................................2
2. Why This Document is Needed .....................................3
3. Encoding an mLDP FEC in the MCAST-VPN NLRI ......................5
4. Wildcards .......................................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
Acknowledgments ...................................................10
Authors' Addresses ................................................10
Many service providers (SPs) offer BGP/MPLS IP VPN service to their customers. When a customer has IP multicast traffic in its VPN, the service provider needs to signal the customer multicast states across the backbone. A customer with IP multicast traffic is typically using PIM (Protocol Independent Multicast) [PIM] and/or IGMP (Internet Group Management Protocol) [IGMP] as the multicast control protocol in its VPN. The IP multicast states of these protocols are commonly denoted as "(S,G)" and/or "(*,G)" states, where "S" is a multicast source address and "G" is a multicast group address. [MVPN-BGP] specifies the way an SP may use BGP to signal a customer's IP multicast states across the SP backbone. This is done by using Multiprotocol BGP Updates whose Subsequent Address Family Identifier (SAFI) values contain the codepoint for MCAST-VPN (as defined in [MVPN-BGP]). The NLRI (Network Layer Reachability Information) field of these BGP Updates includes a customer Multicast Source field and a customer Multicast Group field, thus enabling the customer's (S,G) or (*,G) states to be encoded in the NLRI.
许多服务提供商（SP）向其客户提供BGP/MPLS IP VPN服务。当客户的VPN中存在IP多播流量时，服务提供商需要通过主干向客户多播状态发送信号。具有IP多播流量的客户通常使用PIM（协议独立多播）[PIM]和/或IGMP（互联网组管理协议）[IGMP]作为其VPN中的多播控制协议。这些协议的IP多播状态通常表示为“（S，G）”和/或“（*，G）”状态，其中“S”是多播源地址，“G”是多播组地址。[MVPN-BGP]指定SP可以使用BGP通过SP主干向客户发送IP多播状态信号的方式。这是通过使用多协议BGP更新完成的，这些更新的后续地址族标识符（SAFI）值包含MCAST-VPN的代码点（如[MVPN-BGP]中的定义）。这些BGP更新的NLRI（网络层可达性信息）字段包括客户多播源字段和客户多播组字段，从而使客户的（s，G）或（*，G）状态能够在NLRI中编码。
It is also desirable for the BGP/MPLS IP VPN service to be able to support customers who are using MPLS multicast, either instead of or in addition to IP multicast. This document specifies the procedures and protocol extensions needed to support customers who use mLDP [mLDP] to create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs). While mLDP is not the only protocol that can be used to create and maintain multipoint LSPs, consideration of other MPLS multicast control protocols is outside the scope of this document.
BGP/MPLS IP VPN服务还希望能够支持使用MPLS多播而不是IP多播或除IP多播之外的客户。本文件规定了支持使用mLDP[mLDP]创建和维护点对多点（P2MP）和/或多点对多点（MP2MP）标签交换路径（LSP）的客户所需的程序和协议扩展。虽然mLDP不是可用于创建和维护多点LSP的唯一协议，但对其他MPLS多播控制协议的考虑超出了本文档的范围。
When a customer is using mLDP in its VPN, the customer multicast states associated with mLDP are denoted by an mLDP FEC Element (Forwarding Equivalence Class Element; see [mLDP]) instead of by an (S,G) or (*,G). Thus, it is necessary to have a way to encode a customer's mLDP FEC Elements in the NLRI field of the BGP MCAST-VPN routes.
当客户在其VPN中使用mLDP时，与mLDP关联的客户多播状态由mLDP FEC元素（转发等价类元素；参见[mLDP]）表示，而不是由（S，G）或（*，G）表示。因此，有必要在BGP MCAST-VPN路由的NLRI字段中对客户的mLDP FEC元素进行编码。
While [MVPN-BGP] does specify a way of encoding an mLDP FEC Element in the MCAST-VPN NLRI field, the encoding specified therein makes a variety of restrictive assumptions about the customer's use of mLDP. (These assumptions are described in Section 2 of this document.) The purpose of this document is to update RFC 6514 [MVPN-BGP] so that customers using mLDP in their VPNs can be supported even when those assumptions do not hold.
虽然[MVPN-BGP]在MCAST-VPN NLRI字段中指定了编码mLDP FEC元素的方式，但其中指定的编码对客户使用mLDP做出了各种限制性假设。（本文件第2节描述了这些假设。）本文件的目的是更新RFC 6514[MVPN-BGP]，以便即使这些假设不成立，也可以支持在其VPN中使用mLDP的客户。
Some SPs use the MVPN procedures to provide "global table multicast" service (i.e., multicast service that is not in the context of a VPN) to customers. Methods for doing this are specified in [GTM] and in [SEAMLESS-MCAST]. The procedures described in this document can be used along with the procedures of [GTM] or [SEAMLESS-MCAST] to provide global table multicast service to customers that use MPLS multicast in a global table context.
一些SP使用MVPN过程向客户提供“全局表多播”服务（即不在VPN上下文中的多播服务）。[GTM]和[无缝-MCAST]中规定了执行此操作的方法。本文档中描述的过程可与[GTM]或[无缝-MCAST]的过程一起使用，以向在全局表上下文中使用MPLS多播的客户提供全局表多播服务。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An mLDP FEC Element consists of a FEC Type, a Root Node, and an Opaque Value. mLDP uses several FEC Types and, in particular, uses the FEC Type to distinguish between P2MP LSPs and MP2MP LSPs.
mLDP FEC元素由FEC类型、根节点和不透明值组成。mLDP使用几种FEC类型，特别是使用FEC类型来区分P2MP LSP和MP2MP LSP。
Section 11.1.2 of [MVPN-BGP] ("Originating Routes: mLDP as the C-Multicast Protocol") states:
[MVPN-BGP]（“始发路由：作为C-多播协议的mLDP”）的第11.1.2节规定：
Whenever a PE [Provider Edge router] receives, from one of its CEs [Customer Edge routers], a P2MP Label Map <X, Y, L> over interface I, where X is the Root Node Address, Y is the Opaque Value, and L is an MPLS label ... the PE constructs a Source Tree Join C-multicast route whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y as the Multicast Group field.
每当PE[提供商边缘路由器]从其一个CEs[客户边缘路由器]接收到接口I上的P2MP标签映射<X，Y，L>，其中X是根节点地址，Y是不透明值，L是MPLS标签。。。PE构造一个源树连接C多播路由，其MCAST-VPN NLRI包含X作为多播源字段，Y作为多播组字段。
In other words, the Root Node of the mLDP FEC Element appears in the Multicast Source field, and the Opaque Value of the mLDP FEC Element appears in the Multicast Group field.
换句话说，mLDP FEC元素的根节点出现在多播源字段中，mLDP FEC元素的不透明值出现在多播组字段中。
This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be used if all of the following conditions hold:
在MCAST-VPN NLRI中编码mLDP FEC的这种方法只能在以下所有条件均成立时使用：
1. A customer using mLDP is not also using PIM/IGMP.
1. 使用mLDP的客户也不使用PIM/IGMP。
The encoding in [MVPN-BGP] does not specify any way in which one can determine, upon receiving a BGP Update, whether the Multicast Group field contains an IP address or whether it contains an mLDP FEC Element Opaque Value. Therefore, it might not uniquely identify a customer multicast state if the customer is using both PIM/IGMP and mLDP in its VPN.
[MVPN-BGP]中的编码未指定在接收到BGP更新时可以确定多播组字段是否包含IP地址或mLDP FEC元素不透明值的任何方式。因此，如果客户在其VPN中同时使用PIM/IGMP和mLDP，则可能无法唯一标识客户多播状态。
2. A customer using mLDP is using only the mLDP P2MP FEC Element and is not using the mLDP MP2MP FEC Element.
2. 使用mLDP的客户仅使用mLDP P2MP FEC元件，未使用mLDP MP2MP FEC元件。
The encoding in [MVPN-BGP] does not specify any way to encode the type of the mLDP FEC Element; it just assumes it to be a P2MP FEC Element.
[MVPN-BGP]中的编码未指定任何方式来编码mLDP FEC元素的类型；它只是假设它是一个P2MP FEC元素。
3. A customer using mLDP is using only an mLDP Opaque Value type for which the Opaque Value is exactly 32 bits or 128 bits long.
3. 使用mLDP的客户仅使用其不透明值正好为32位或128位长的mLDP不透明值类型。
The use of Multicast Group fields that have other lengths is declared by [MVPN-BGP] to be "out of scope" of that document (see, e.g., Section 4.3 of that document).
[MVPN-BGP]将具有其他长度的多播组字段的使用声明为该文档的“超出范围”（例如，参见该文档的第4.3节）。
This condition holds if the customer uses only the mLDP "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). However, mLDP supports many other Opaque Value types whose length is not restricted to be 32 or 128 bits.
如果客户仅使用mLDP“通用LSP标识符”不透明值类型（在[mLDP]中定义），则此条件成立。但是，mLDP支持许多其他不透明值类型，其长度不限于32或128位。
The purpose of this document is to update [MVPN-BGP] so that customers using mLDP can be supported, even when these conditions do not hold.
本文件的目的是更新[MVPN-BGP]，以便支持使用mLDP的客户，即使这些条件不适用。
When mLDP is used as the customer multicast control protocol, [MVPN-BGP] presupposes that an mLDP FEC Element will be encoded in the NLRI of the following three MCAST-VPN route types:
当mLDP用作客户多播控制协议时，[MVPN-BGP]假定mLDP FEC元素将编码在以下三种MCAST-VPN路由类型的NLRI中：
- C-multicast Source Tree Join route,
- C-多播源树加入路由，
- S-PMSI A-D route, and
- S-PMSI A-D路线，以及
- Leaf A-D route.
- 叶A-D路线。
The other four MCAST-VPN route types defined in [MVPN-BGP] do not ever need to carry mLDP FEC Elements. The C-multicast Shared Tree Join route and the Source Active A-D route are used to communicate state about unidirectional shared trees; since mLDP does not have unidirectional shared trees, these routes are not used to signal mLDP states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D route do not identify specific customer multicast states and hence do not carry any information that is specific to the customer's multicast control protocol.
[MVPN-BGP]中定义的其他四种MCAST-VPN路由类型不需要携带mLDP FEC元素。C组播共享树连接路由和源活动A-D路由用于单向共享树的状态通信；由于mLDP没有单向共享树，因此这些路由不用于向mLDP状态发送信号。内部AS I-PMSI A-D路由和内部AS I-PMSI A-D路由不识别特定的客户多播状态，因此不携带特定于客户的多播控制协议的任何信息。
This document defines three new route types:
本文件定义了三种新的路线类型：
- C-Multicast Source Tree Join route for C-multicast mLDP,
- C-多播mLDP的C-多播源树加入路由，
- S-PMSI A-D route for C-multicast mLDP, and
- 用于C多播mLDP的S-PMSI A-D路由，以及
- Leaf A-D route for C-multicast mLDP.
- 用于C多播mLDP的叶A-D路由。
The term "C-multicast mLDP" in the names of these route types is intended to indicate that the NLRI of these routes contains mLDP FEC Elements.
这些路由类型名称中的术语“C-multicast mLDP”旨在指示这些路由的NLRI包含mLDP FEC元素。
Each of these route types corresponds to a route type defined in [MVPN-BGP]. IANA has been requested to allocate codepoints for these three route types such that (a) the high-order two bits have the value 0x01, and (b) the low-order six bits have the same value as the codepoints for the corresponding route types from [MVPN-BGP].
每种路由类型都对应于[MVPN-BGP]中定义的路由类型。已要求IANA为这三种路由类型分配代码点，以便（a）高阶两位的值为0x01，以及（b）低阶六位的值与[MVPN-BGP]中相应路由类型的代码点的值相同。
In general, the procedures defined in other MVPN specifications for the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the Leaf A-D route also apply to the C-Multicast Source Tree Join route for C-multicast mLDP, the S-PMSI A-D route for C-multicast mLDP, and the Leaf A-D route for C-multicast mLDP, respectively. However, the NLRI of these three new route types is constructed differently than the NLRI of the corresponding routes from [MVPN-BGP]: the Multicast Source Length, Multicast Source, Multicast Group Length, and
一般来说，其他MVPN规范中定义的C-多播源树连接路由、S-PMSI A-D路由和叶A-D路由的过程也分别适用于C-多播mLDP的C-多播源树连接路由、C-多播mLDP的S-PMSI A-D路由和C-多播mLDP的叶A-D路由。然而，这三种新路由类型的NLRI的构造不同于[MVPN-BGP]中相应路由的NLRI：多播源长度、多播源、多播组长度和
Multicast Group fields are omitted, and in their place is a single mLDP FEC Element, as defined in [mLDP]. (See Section 2.2 of [mLDP] for a diagram of the mLDP FEC Element.)
多播组字段被省略，取而代之的是一个mLDP FEC元素，如[mLDP]中所定义。（有关mLDP FEC元件的示意图，请参见[mLDP]第2.2节。）
As a result, the NLRI of an S-PMSI A-D route for C-multicast mLDP will consist of a Route Distinguisher, followed by the mLDP FEC, followed by the Originating Router's IP Address field.
因此，C-多播mLDP的S-PMSI a-D路由的NLRI将由路由识别器组成，后面是mLDP FEC，后面是发起路由器的IP地址字段。
The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP will consist of a Route Distinguisher, followed by the Source AS, followed by the mLDP FEC.
C-多播mLDP的C-多播源树连接路由的NLRI将由一个路由识别器组成，后面是源AS，后面是mLDP FEC。
In a Leaf A-D route for C-multicast mLDP that has been derived from an S-PMSI A-D route for C-multicast mLDP, the Route Key field remains the NLRI of the S-PMSI A-D route from which it was derived.
在从C-multicast mLDP的S-PMSI a-D路由派生的C-multicast mLDP的叶a-D路由中，路由密钥字段仍然是从中派生的S-PMSI a-D路由的NLRI。
In a Leaf A-D route for C-multicast mLDP that has not been derived from an S-PMSI A-D, the Route Key field is as specified in [SEAMLESS-MCAST], except that the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields are omitted, and in their place is a single mLDP FEC Element. Thus, the Route Key field consists of a Route Distinguisher, an mLDP FEC Element, and the IP address of the Ingress PE router.
在未从S-PMSI a-D派生的C-多播mLDP的叶a-D路由中，路由密钥字段如[SEAMLESS-MCAST]中所规定，只是省略了多播源长度、多播源、多播组长度和多播组字段，取而代之的是单个mLDP FEC元素。因此，路由密钥字段由路由识别器、mLDP FEC元素和入口PE路由器的IP地址组成。
Please note that [BGP-ERR], Section 5.4 ("Typed NLRI") is applicable if the Route Type field of the NLRI of a received MCAST-VPN route contains an unrecognized value. Any such routes will be discarded.
请注意，如果收到的MCAST-VPN路由的NLRI的路由类型字段包含无法识别的值，则[BGP-ERR]第5.4节（“类型化NLRI”）适用。任何此类路线都将被丢弃。
An mLDP FEC Element contains an address family field whose value is from IANA's "Address Family Numbers" registry. The value of the address family field identifies the address family of the Root Node Address field of the FEC Element. When an mLDP FEC Element is encoded into the NLRI of a BGP Update whose SAFI is MCAST-VPN, the address family of the Root Node Address (as indicated in the FEC Element) MUST correspond to the address family that is identified in the Address Family Identifier (AFI) field of that BGP Update. These two address family fields are considered to correspond to each other under the following conditions:
mLDP FEC元素包含一个地址族字段，其值来自IANA的“地址族编号”注册表。地址族字段的值标识FEC元素的根节点地址字段的地址族。当mLDP FEC元素编码到SAFI为MCAST-VPN的BGP更新的NLRI中时，根节点地址的地址族（如FEC元素中所示）必须对应于该BGP更新的地址族标识符（AFI）字段中标识的地址族。在以下条件下，这两个地址族字段被视为相互对应：
- they contain identical values,
- 它们包含相同的值，
- the BGP Update's AFI field identifies IPv4 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv4" as the address family of the Root Node, or
- BGP更新的AFI字段将IPv4标识为地址族，mLDP FEC元素将“多拓扑IPv4”标识为根节点的地址族，或
- the BGP Update's AFI field identifies IPv6 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv6" as the address family of the Root Node.
- BGP更新的AFI字段将IPv6标识为地址族，mLDP FEC元素将“多拓扑IPv6”标识为根节点的地址族。
For more information about the "multi-topology" address families, see [LDP-MT] and [mLDP-MT].
有关“多拓扑”地址族的更多信息，请参阅[LDP-MT]和[mLDP-MT]。
[MVPN-WILDCARDS] specifies encodings and procedures that allow "wildcards" to be specified in the NLRI of S-PMSI A-D routes. A set of rules are given that specify when a customer multicast flow "matches" a given S-PMSI A-D route whose NLRI contains wildcards. However, the use of these wildcards is defined only for the case where the customer is using PIM as its multicast control protocol. The use of wildcards when the customer is using mLDP as its multicast control protocol is outside the scope of this document.
[MVPN-通配符]指定允许在S-PMSI A-D路由的NLRI中指定“通配符”的编码和过程。给出了一组规则，用于指定客户多播流何时“匹配”NLRI包含通配符的给定S-PMSI A-D路由。但是，这些通配符的使用仅限于客户使用PIM作为其多播控制协议的情况。当客户使用mLDP作为其多播控制协议时，通配符的使用超出了本文档的范围。
[MVPN-BGP] does not create a registry for the allocation of new MCAST-VPN Route Type values. In retrospect, it seems that it should have done so. IANA has created a new registry called "BGP MCAST-VPN Route Types", which references this document and [MVPN-BGP]. The registry has been created under the top-level registry: "Border Gateway Protocol (BGP) Parameters" <http://www.iana.org/assignments/bgp-parameters>. The allocation policy is "Standards Action". Values may be assigned from one of several ranges:
[MVPN-BGP]没有为分配新的MCAST-VPN路由类型值创建注册表。回顾过去，它似乎应该这样做。IANA创建了一个名为“BGP MCAST-VPN路由类型”的新注册表，该注册表引用了本文档和[MVPN-BGP]。已在顶级注册表“边界网关协议（BGP）参数”下创建注册表<http://www.iana.org/assignments/bgp-parameters>. 分配政策是“标准行动”。可以从以下几个范围之一指定值：
- Range 0x01-0x3f: Generic/PIM Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that PIM or IGMP is the C-multicast control protocol or when the NLRI format associated with the route type is independent of the C-multicast control protocol.
- 范围0x01-0x3f：通用/PIM范围。当与路由类型关联的NLRI格式假定PIM或IGMP是C-多播控制协议时，或者当与路由类型关联的NLRI格式独立于C-多播控制协议时，从该范围分配值。
- Range 0x43-0x7f: mLDP Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that mLDP is the C-multicast control protocol.
- 范围0x43-0x7f:mLDP范围。当与路由类型关联的NLRI格式假定mLDP是C-多播控制协议时，将从此范围分配值。
- Range 0x80-0xff: This range is reserved; values should not be assigned from this range.
- 范围0x80-0xff：此范围为保留范围；不应从该范围指定值。
In general, whenever an assignment is requested from this registry, two codepoints should be requested at the same time: one from the Generic/PIM range and one from the mLDP range. The two codepoints should have the same low-order 6 bits. If one of the two codepoints is not actually needed, it should be registered anyway and marked as "Reserved".
通常，每当从该注册表请求分配时，应同时请求两个代码点：一个来自通用/PIM范围，另一个来自mLDP范围。两个代码点应具有相同的低阶6位。如果实际上不需要两个代码点中的一个，则应将其注册并标记为“保留”。
The "BGP MCAST-VPN Route Types" contains the following initial assignments:
“BGP MCAST-VPN路由类型”包含以下初始分配：
Value Meaning Reference
--------- ---------------------------------- -------------------
0x00 Reserved This RFC
Value Meaning Reference
--------- ---------------------------------- -------------------
0x00 Reserved This RFC
0x01 Intra-AS I-PMSI A-D route This RFC, [RFC6514]
0x01内部AS I-PMSI A-D路由此RFC[RFC6514]
0x02 Inter-AS I-PMSI A-D route This RFC, [RFC6514]
0x02内部AS I-PMSI A-D路由此RFC[RFC6514]
0x03 S-PMSI A-D route This RFC, [RFC6514]
0x03 S-PMSI A-D路由此RFC[RFC6514]
0x04 Leaf A-D route This RFC, [RFC6514]
0x04叶A-D路由此RFC，[RFC6514]
0x05 Source Active A-D route This RFC, [RFC6514]
0x05源激活A-D路由此RFC[RFC6514]
0x06 Shared Tree Join route This RFC, [RFC6514]
0x06共享树加入路由此RFC，[RFC6514]
0x07 Source Tree Join route This RFC, [RFC6514]
0x07源树加入路由此RFC，[RFC6514]
0x08-0x3f Unassigned (Generic/PIM range) This RFC
0x08-0x3f未分配（通用/PIM范围）此RFC
0x40-0x42 Reserved This RFC
0x40-0x42保留此RFC
0x43 S-PMSI A-D route for C-multicast mLDP This RFC
0x43 C-multicast mLDP此RFC的S-PMSI A-D路由
0x44 Leaf A-D route for C-multicast mLDP This RFC
0x44此RFC的C多播mLDP的叶A-D路由
0x45-0x46 Reserved This RFC
0x45-0x46保留此RFC
0x47 Source Tree Join route for C-multicast mLDP This RFC
0x47此RFC的C多播mLDP的源树加入路由
0x48-0x7f Unassigned (mLDP range) This RFC
0x48-0x7f未分配（mLDP范围）此RFC
0x80-0xff Reserved This RFC
0x80-0xff保留此RFC
This document specifies a method of encoding an mLDP FEC Element in the NLRI of some of the BGP Update messages that are specified in [MVPN-BGP]. The security considerations of [mLDP] and of [MVPN-BGP] are applicable, but no new security considerations are raised.
本文件规定了在[MVPN-BGP]中指定的某些BGP更新消息的NLRI中编码mLDP FEC元素的方法。[mLDP]和[MVPN-BGP]的安全注意事项适用，但未提出新的安全注意事项。
[mLDP] 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, <http://www.rfc-editor.org/info/rfc6388>.
[mLDP]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[MVPN-BGP] 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>.
[MVPN-BGP]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中多播的BGP编码和过程”，RFC 6514，2012年2月<http://www.rfc-editor.org/info/rfc6514>.
[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>.
[BGP-ERR] Chen, E., Ed, Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, draft-ietf-idr-error-handling-18, December 2014.
[BGP-ERR]Chen，E.，Ed，Scudder，J.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，正在进行的工作，草稿-ietf-idr-Error-Handling-18，2014年12月。
[GTM] Zhang, J., Giuliano, L., Rosen, E., Ed., 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.，Giuliano，L.，Rosen，E.，Ed.，Subramanian，K.，Pacella，D.，和J.Schiller，“使用BGP-MVPN过程的全局表多播”，正在进行的工作，草稿-ietf-bess-MVPN-Global-Table-mcast-00，2014年11月。
[IGMP] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[IGMP]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月<http://www.rfc-editor.org/info/rfc3376>.
[LDP-MT] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, July 2014, <http://www.rfc-editor.org/info/rfc7307>.
[LDP-MT]Zhao，Q.，Raza，K.，Zhou，C.，Fang，L.，Li，L.，和D.King，“多拓扑的LDP扩展”，RFC 7307，2014年7月<http://www.rfc-editor.org/info/rfc7307>.
[mLDP-MT] Wijnands, IJ. and K. Raza, "mLDP Extensions for Multi Topology Routing", Work in Progress, draft-iwijnand-mpls-mldp-multi-topology-03, June 2013.
[mLDP MT]伊利诺伊州威兰德。和K.Raza，“用于多拓扑路由的mLDP扩展”，正在进行的工作，草稿-iwijnand-mpls-mLDP-Multi-Topology-032013年6月。
[MVPN-WILDCARDS] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[MVPN-通配符]Rosen，E.，Ed.，Rekhter，Y.，Ed.，Hendrickx，W.，和R.Qiu，“多播VPN自动发现路由中的通配符”，RFC 66252012年5月<http://www.rfc-editor.org/info/rfc6625>.
[PIM] 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>.
[PIM]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月<http://www.rfc-editor.org/info/rfc4601>.
[SEAMLESS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Segmented LSPs", Work in Progress, draft-ietf-mpls-seamless-mcast-14, June 2014.
[SEAMLESS-MCAST]Rekhter，Y.，Aggarwal，R.，Morin，T.，Grossclaude，I.，Leymann，N.，和S.Saad，“区域间P2MP分段LSP”，正在进行的工作，草案-ietf-mpls-SEAMLESS-MCAST-14，2014年6月。
Acknowledgments
致谢
The authors wish to thank Pradosh Mohapatra and Saquib Najam for their ideas and comments. We also thank Yakov Rekhter and Martin Vigoureux for their comments.
作者希望感谢Pradosh Mohapatra和Saquib Najam的想法和评论。我们还感谢亚科夫·雷赫特和马丁·维古鲁的评论。
Authors' Addresses
作者地址
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时电子邮件：ice@cisco.com
Eric C. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States EMail: erosen@juniper.net
Eric C.Rosen Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886电子邮件：erosen@juniper.net
Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany EMail: Uwe.Joorde@telekom.de
Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany电子邮件：Uwe。Joorde@telekom.de