Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 6512 E. Rosen
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Napierala
AT&T
N. Leymann
Deutsche Telekom
February 2012
Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 6512 E. Rosen
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Napierala
AT&T
N. Leymann
Deutsche Telekom
February 2012
Using Multipoint LDP When the Backbone Has No Route to the Root
骨干网无根路由时使用多点LDP
Abstract
摘要
The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node.
用于构造点对多点和多点对多点标签交换路径（“MP LSP”）的控制协议包含一个标识“根节点”地址的字段。中间节点应能够在其路由表中查找该地址。但是，如果到根节点的路由是BGP路由，并且中间节点是BGP空闲核心的一部分，则这是不可能的。本文件规定了通过无BGP内核构建MP 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/rfc6512.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6512.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
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.
本文件的出版。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. The Recursive Opaque Value ......................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
3. The VPN-Recursive Opaque Value ..................................6
3.1. Encoding ...................................................6
3.2. Procedures .................................................7
3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
3.2.2. Limited Carrier's Carrier Function ..................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction ....................................................3
2. The Recursive Opaque Value ......................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
3. The VPN-Recursive Opaque Value ..................................6
3.1. Encoding ...................................................6
3.2. Procedures .................................................7
3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
3.2.2. Limited Carrier's Carrier Function ..................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
The document [mLDP] extends LDP [LDP] to support multipoint Label Switched Paths. These extensions are known as "Multipoint LDP", or more simply, as "mLDP". [mLDP] defines several LDP Forwarding Equivalence Class (FEC) element encodings: "Point-to-Multipoint" (P2MP), "Multipoint-to-Multipoint (MP2MP) Upstream", and "MP2MP Downstream".
文档[mLDP]扩展了LDP[LDP]以支持多点标签交换路径。这些扩展称为“多点LDP”，或者更简单地说，称为“mLDP”。[mLDP]定义了几个LDP转发等价类（FEC）元素编码：“点对多点”（P2MP）、“多点对多点（MP2MP）上游”和“MP2MP下游”。
The encoding for these three FEC elements, as defined in [mLDP], is shown in Figure 1.
图1显示了[mLDP]中定义的这三个FEC元素的编码。
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 | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| Opaque Value |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| Opaque Value |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: mLDP FEC Element Encoding
图1:mLDP FEC元素编码
Note that a P2MP or MP2MP Label Switched Path ("MP LSP") is identified by the combination of a "root node" and a variable length "opaque value". The root node also plays a special role in the mLDP procedures: mLDP messages that are "about" a particular MP LSP are forwarded to the LDP adjacency that is the next hop on the route to the root node.
请注意，P2MP或MP2MP标签交换路径（“MP LSP”）由“根节点”和可变长度“不透明值”的组合标识。根节点在mLDP过程中也起着特殊的作用：关于特定MP LSP的mLDP消息被转发到LDP邻接处，LDP邻接处是到根节点的路由上的下一跳。
Sometimes, it is desirable for an MP LSP to pass through a part of the network in which there is no route to the root node. For instance, consider the topology of Figure 2.
有时，希望MP LSP通过网络中没有到根节点的路由的部分。例如，考虑图2的拓扑结构。
CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
Figure 2
图2
In Figure 2, CE1 and CE2 are "Customer Edge routers", R is a customer router at the same VPN site as CE2, and PE1 and PE2 are "Provider Edge routers". Suppose that PE1 has a BGP-learned route for R, with
在图2中，CE1和CE2是“客户边缘路由器”，R是与CE2位于同一VPN站点的客户路由器，PE1和PE2是“提供商边缘路由器”。假设PE1有一个用于R的BGP学习路由，其中
PE2 as the BGP next hop. Suppose also that the provider's interior routers (such as P1 and P2) do not have any BGP-learned routes and, in particular, do not have any routes to R.
PE2作为BGP下一跳。还假设提供商的内部路由器（如P1和P2）没有任何BGP学习路由，尤其是没有任何到R的路由。
In such an environment, unicast data packets from CE1 addressed to R would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and forwarded to CE2.
在这样的环境中，从CE1发送到R的单播数据包将被PE1封装，通过隧道传输到PE2，由PE2解封，然后转发到CE2。
Suppose now that CE1 is trying to set up an MP LSP whose root is R, and the intention is that the provider's network will participate in the construction of the LSP. Then, the mLDP messages identifying the LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to PE2, from PE2 to CE2, and from CE2 to R.
假设现在CE1正试图建立一个根为R的MP LSP，其目的是提供商的网络将参与LSP的构建。然后，标识LSP的mLDP消息必须从CE1传递到PE1，从PE1传递到P1，…，从P2传递到PE2，从PE2传递到CE2，从CE2传递到R。
To begin the process, CE1 creates an MP FEC element with the address of R as the root node address and passes that FEC element via mLDP to PE1. However, PE1 cannot use this same FEC element to identify the LSP in the LDP messages it sends to P1, because P1 does not have a route to R.
为了开始该过程，CE1创建了一个MP FEC元素，其地址R作为根节点地址，并通过mLDP将该FEC元素传递给PE1。然而，PE1不能使用相同的FEC元素来识别它发送给P1的LDP消息中的LSP，因为P1没有到R的路由。
However, PE1 does know that PE2 is the BGP next hop on the path to R. What is needed is a method whereby:
然而，PE1确实知道PE2是通往R的路径上的BGP下一跳。需要的是一种方法，通过该方法：
- PE1 can tell P1 to set up an LSP as if the root node were PE2,
- PE1可以告诉P1设置LSP，就像根节点是PE2一样，
- PE2 can determine that the LSP in question is really rooted at R, not at PE2 itself, and
- PE2可以确定所讨论的LSP实际上是根植于R，而不是PE2本身，并且
- PE2 can determine the original FEC element that CE1 passed to PE1, so that PE2 can pass it on to CE2.
- PE2可以确定CE1传递给PE1的原始FEC元素，以便PE2可以将其传递给CE2。
This document defines the procedures that allow CE1 to create an LSP rooted at R. These procedures require PE1 to modify the MP FEC element before sending an mLDP message to P1. The modified FEC element has PE2 as the root and the original FEC element as the opaque value. This requires a new type of opaque value. Since the opaque value contains a FEC element, we call this a "Recursive Opaque Value". When PE2 sends an mLDP message to CE2, it replaces the FEC element with the opaque value, thus undoing the recursion. Details are in Section 2.
本文件定义了允许CE1创建以R为根的LSP的程序。这些程序要求PE1在向P1发送mLDP消息之前修改MP FEC元素。修改后的FEC元素以PE2为根，原始FEC元素为不透明值。这需要一种新类型的不透明值。由于不透明值包含一个FEC元素，我们称之为“递归不透明值”。当PE2向CE2发送mLDP消息时，它用不透明值替换FEC元素，从而撤消递归。详情见第2节。
Section 3 defines the "VPN-Recursive Opaque Value". Whereas the "Recursive Opaque Value" carries the original FEC, the "VPN-Recursive Opaque Value" carries the original FEC plus a Route Distinguisher (RD). This is applicable when MP LSPs are being used to carry the multicast traffic of a VPN [MVPN]. Details are in Section 3.
第3节定义了“VPN递归不透明值”。“递归不透明值”携带原始FEC，“VPN递归不透明值”携带原始FEC加上路由识别器（RD）。这适用于MP LSP用于承载VPN[MVPN]的多播流量的情况。详情见第3节。
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]中所述进行解释。
We define a new type of opaque value, the Recursive Opaque Value. This is a "basic type", identified by a 1-octet type field.
我们定义了一种新类型的不透明值，递归不透明值。这是一个“基本类型”，由一个1-octet类型字段标识。
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 = 7 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 7 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Recursive Opaque Value
图3：递归不透明值
The value field of the Recursive Opaque Value is itself a P2MP or MP2MP FEC element, encoded exactly as specified in [mLDP], with a type field, a length field, and value field of its own. The length of the Recursive Opaque Value thus includes the lengths of the type, length, and value fields of the contained FEC element.
递归不透明值的值字段本身是一个P2MP或MP2MP FEC元素，编码方式与[mLDP]中的规定完全一致，具有类型字段、长度字段和自身的值字段。因此，递归不透明值的长度包括所包含FEC元素的类型、长度和值字段的长度。
In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP FEC element whose root node is R and whose opaque value is Q. We will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC as an ordered pair, as follows:
在图2的拓扑结构中，假设CE1向PE1发送一个MP FEC元素，其根节点为R，不透明值为Q。我们将此FEC元素称为“CE1-FEC”。我们可以将CE1-FEC视为有序对，如下所示：
CE1-FEC = <root=R, opaque_value=Q>.
CE1-FEC = <root=R, opaque_value=Q>.
PE1 determines that the root node R matches a BGP route, with a BGP next hop of PE2. PE1 also knows by its configuration that the interior routers on the path to PE2 are "BGP-free" and thus have no route to R.
PE1确定根节点R与BGP路由匹配，BGP下一跳为PE2。PE1还通过其配置知道，通往PE2的路径上的内部路由器是“无BGP的”，因此没有通往R的路由。
PE1 therefore creates a new MP FEC element, whose root node address is the address of PE2 and whose opaque value is a Recursive Opaque Value whose value field contains CE1-FEC. We refer to this FEC element as PE2-FEC:
因此，PE1创建一个新的MP FEC元素，其根节点地址是PE2的地址，其不透明值是一个递归不透明值，其值字段包含CE1-FEC。我们将该FEC元素称为PE2-FEC：
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
PE2-FEC = <root=PE2, opaque_value=<root=R,
opaque_value=Q>>
PE2-FEC = <root=PE2, opaque_value=<root=R,
opaque_value=Q>>
PE1 then sends this FEC element to P1.
然后，PE1将该FEC元素发送给P1。
As far as the interior routers are concerned, they are being requested to build an MP LSP whose root node is PE2. They MUST NOT interpret the opaque value at all.
就内部路由器而言，它们被要求构建一个根节点为PE2的MP LSP。他们绝对不能解释不透明值。
When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the identified root node and that the opaque value is a Recursive Opaque Value. Therefore, PE2 MUST replace PE2-FEC with the contents of the Recursive Opaque Value (i.e., with CE1-FEC) before doing any further processing. This will result in CE1-FEC being sent on to CE2, and further from CE2 to R. Note that CE1-FEC will contain the LSP root node specified by CE1; the presumption is that PE2 has a route to this root node.
当PE2-FEC到达PE2时，PE2注意到它（PE2）是已识别的根节点，并且不透明值是递归不透明值。因此，在进行任何进一步处理之前，PE2必须用递归不透明值的内容（即CE1-FEC）替换PE2-FEC。这将导致CE1-FEC被发送到CE2，并进一步从CE2发送到R。请注意，CE1-FEC将包含CE1指定的LSP根节点；假设PE2有一条到这个根节点的路由。
We define a new type of opaque value, the VPN-Recursive Opaque Value. This is a "basic type", identified by a 1-octet type field.
我们定义了一种新类型的不透明值，VPN递归不透明值。这是一个“基本类型”，由一个1-octet类型字段标识。
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 = 8 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 8 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VPN-Recursive Opaque Value
图4:VPN递归不透明值
The value field of the VPN-Recursive Opaque Value consists of an 8-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC element, encoded exactly as specified in [mLDP], with a type field, a length field, and value field of is own. The length of the VPN-Recursive Opaque Value thus includes the 8 octets of RD plus the
VPN递归不透明值的值字段由一个8位字节的路由识别器（RD）组成，后跟一个P2MP或MP2MP FEC元素，按照[mLDP]中的规定进行编码，类型字段、长度字段和值字段都是自己的。因此，VPN递归不透明值的长度包括RD的8个八位字节加上
lengths of the type, length, and values fields of the contained FEC element.
包含的FEC元素的类型、长度和值字段的长度。
Consider the inter-AS (Autonomous System) VPN scenario depicted in Figure 5.
考虑图5中描述的AS间（自治系统）VPN场景。
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
Figure 5
图5
Suppose this is an "option B" VPN interconnect ([VPN], Section 10). This means that the Autonomous System Border Router (ASBR) in the first Autonomous System (i.e., ASBR1) does not have a route to PE routers in other ASes (such as PE2). Suppose also that the Multicast VPN (MVPN) policy is to instantiate Provider Multicast Service Interfaces (PMSIs) [MVPN] using mLDP and that "non-segmented inter-AS P-tunnels" [MVPN] are being used.
假设这是一个“选项B”VPN互连（[VPN]，第10节）。这意味着第一自治系统（即ASBR1）中的自治系统边界路由器（ASBR）没有到其他as（例如PE2）中的PE路由器的路由。还假设多播VPN（MVPN）策略是使用mLDP实例化提供商多播服务接口（PMSI）[MVPN]，并且正在使用“非分段的内部AS P隧道”[MVPN]。
In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root is PE2. P1 has no route to PE2, and all PE1 knows about the route to PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2, PE1 needs to originate an mLDP message with a FEC element that identifies ASBR1 as the root. This FEC element must contain enough information to enable ASBR1 to find the next hop towards PE2 even though ASBR1 does not have a route to PE2.
在这种情况下，PE1可能需要加入根为PE2的P2MP或MP2MP LSP。P1没有到PE2的路由，PE1只知道到PE2的路由是ASBR1是BGP下一跳。由于P1与PE2之间没有根，PE1需要使用将ASBR1标识为根的FEC元素来发起mLDP消息。此FEC元素必须包含足够的信息，以使ASBR1能够找到通往PE2的下一个跃点，即使ASBR1没有通往PE2的路由。
Although ASBR1 does not have a route to PE2, it does have a BGP Intra-AS Inclusive PMSI (I-PMSI) auto-discovery (A-D) route [MVPN] whose Network Layer Reachability Information (NLRI) contains PE2's IP address together with a particular RD. PE1 also has this Inter-AS I-PMSI A-D route. The LSP needs to be set up along the path established by the Intra-AS I-PMSI A-D routes. Therefore, one must use a Recursive FEC element that contains the RD as well as the address of PE2. The "VPN-Recursive FEC Element" defined herein is used for this purpose.
尽管ASBR1没有到PE2的路由，但它有一个BGP内部AS包容性PMSI（I-PMSI）自动发现（a-D）路由[MVPN]，其网络层可达性信息（NLRI）包含PE2的IP地址和特定的RD。PE1也有这个内部AS I-PMSI a-D路由。LSP需要沿着内部AS I-PMSI A-D路由建立的路径设置。因此，必须使用包含RD和PE2地址的递归FEC元素。本文定义的“VPN递归FEC元素”用于此目的。
This enables us to provide the same functionality for mLDP P-tunnels that is provided for PIM P-tunnels in Section 8.1.3.2 of [MVPN] through the use of the MVPN Join Attribute.
这使我们能够通过使用MVPN连接属性，为mLDP P隧道提供与[MVPN]第8.1.3.2节中PIM P隧道相同的功能。
At PE1 in Figure 4, the LSP to be created is associated with a particular VPN Routing and Forwarding Table (VRF). PE1 looks up in that VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that the BGP next hop of that route is ASBR1. So, it creates a P2MP or MP2MP FEC element whose root is ASBR1 and whose opaque value is a VPN-Recursive FEC element. The VPN-Recursive FEC element itself consists of a root, an RD, and an opaque value, set as follows:
在图4的PE1中，要创建的LSP与特定的VPN路由和转发表（VRF）相关联。PE1在该VRF中查找由PE2发起的内部AS I-PMSI A-D路由。它发现该路由的BGP下一跳是ASBR1。因此，它创建一个根为ASBR1、不透明值为VPN递归FEC元素的P2MP或MP2MP FEC元素。VPN递归FEC元素本身由根、RD和不透明值组成，设置如下：
- The root is PE2.
- 根是PE2。
- The RD is the RD from the NLRI of the Intra-AS A-D route originated by PE2.
- RD是来自PE2发起的内部AS A-D路由的NLRI的RD。
- The opaque value is chosen (by some method outside the scope of this document) so as to be unique in the context of PE2. (For example, it may have been specified in a PMSI Tunnel Attribute originated by PE2.) We will refer to this opaque value as "Q".
- 不透明值的选择（通过本文件范围外的某种方法）在PE2的上下文中是唯一的。（例如，它可能已在由PE2发起的PMSI隧道属性中指定。）我们将此不透明值称为“Q”。
The resulting FEC element can be informally represented as
由此产生的FEC元素可以非正式地表示为
<root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.
<root=ASBR1，不透明值=<root=PE2，RD，不透明值=Q>>。
PE1 can now begin setting up the LSP by using this FEC element in an LDP Label Mapping message sent towards ASBR1.
PE1现在可以通过在发送到ASBR1的LDP标签映射消息中使用该FEC元素开始设置LSP。
When ASBR1 receives, over a non-VRF interface, an mLDP Label Mapping message containing this FEC element, it sees that it is the root and that the opaque value is a VPN-Recursive Opaque Value. It parses the VPN-Recursive Opaque value and extracts the root value, PE2.
当ASBR1通过非VRF接口接收到包含此FEC元素的mLDP标签映射消息时，它会看到它是根，并且不透明值是VPN递归不透明值。它解析VPN递归不透明值并提取根值PE2。
If ASBR1 has a route to PE2, it continues setting up the LSP by using the following FEC element:
如果ASBR1有到PE2的路由，它将使用以下FEC元素继续设置LSP：
<root=PE2, opaque_value=Q>
<root=PE2, opaque_value=Q>
However, if ASBR1 does not have a route to PE2, it looks for an Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along with the specified RD value. Say the BGP next hop of that route is ASBR2. Then ASBR1 continues setting up the LSP by using the following FEC element:
但是，如果ASBR1没有到PE2的路由，它将查找其NLRI包含PE2地址和指定RD值的内部AS I-PMSI a-D路由。假设该路由的BGP下一跳是ASBR2。然后，ASBR1使用以下FEC元素继续设置LSP：
<root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>.
<root=ASBR2，不透明值=<root=PE2，RD，不透明值=Q>>。
Note that in this case, the root has changed from ASBR1 to ASBR2, but the opaque value is the unchanged VPN-Recursive FEC element.
请注意，在本例中，根已从ASBR1更改为ASBR2，但不透明值是未更改的VPN递归FEC元素。
Another possible use of the VPN-Recursive FEC is to provide a limited version of "Carrier's Carrier Service". Referring again to the topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC element whose root node is R and whose opaque value is Q. We will refer to this FEC element as "CE1-FEC". However, PE1's route to R will be in a VRF. Therefore, the FEC element created by PE1 must contain some identifier that PE2 can use to find the proper VRF in which to look up the address of R.
VPN递归FEC的另一个可能用途是提供有限版本的“运营商的运营商服务”。再次参考图2的拓扑结构，假设PE1/PE2向CE1/CE2提供“运营商的运营商VPN服务”[VPN]。CE1向PE1发送一个MP FEC元素，其根节点为R，不透明值为Q。我们将此FEC元素称为“CE1-FEC”。然而，PE1到R的路线将在VRF中。因此，由PE1创建的FEC元素必须包含一些标识符，PE2可以使用这些标识符找到适当的VRF，在其中查找R的地址。
When PE1 looks up the address of R in a VRF, it will find a route in the VPN-IP address family. The next hop will be PE2, but there will also be a Route Distinguisher (RD) as part of that NLRI of the matching route. In this case, the new FEC element created by PE1 has the address of PE2 as the root node address and has a VPN-Recursive Opaque Value. The value field of the VPN-Recursive Opaque Value consists of the 8-octet RD followed by CE1-FEC.
当PE1在VRF中查找R的地址时，它将在VPN-IP地址族中找到一条路由。下一跳将是PE2，但也将有一个路由识别器（RD）作为匹配路由的NLRI的一部分。在这种情况下，由PE1创建的新FEC元素的根节点地址为PE2，并且具有VPN递归不透明值。VPN递归不透明值的值字段由8个八位组RD和CE1-FEC组成。
As far as the interior routers are concerned, they are being requested to build an MP LSP whose root node is PE2. They MUST NOT interpret the opaque value at all.
就内部路由器而言，它们被要求构建一个根节点为PE2的MP LSP。他们绝对不能解释不透明值。
When an mLDP Label Mapping message containing PE2-FEC arrives at PE2 over a VRF interface, PE2 notes that it is the identified root node and that the opaque value is a VPN-Recursive Opaque Value. Therefore, it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque Value (i.e., with CE1-FEC) before doing any further processing. It uses the VRF to look up the path to R. This will result in CE1-FEC being sent on to CE2, and presumably further from CE2 to R.
当包含PE2-FEC的mLDP标签映射消息通过VRF接口到达PE2时，PE2注意到它是已识别的根节点，并且不透明值是VPN递归不透明值。因此，在进行任何进一步处理之前，它必须用VPN递归不透明值的内容（即CE1-FEC）替换PE2-FEC。它使用VRF查找到R的路径。这将导致CE1-FEC被发送到CE2，并可能从CE2进一步发送到R。
In this scenario, the RD in the VPN-Recursive Opaque Value also ensures uniqueness of the FEC element within the inner carrier's network.
在这种情况下，VPN递归不透明值中的RD还确保内部运营商网络中FEC元素的唯一性。
This way of providing Carrier's Carrier service has limited applicability, as it only works under the following conditions:
这种提供承运人承运人服务的方式具有有限的适用性，因为它只能在以下条件下工作：
- Both the inner carrier and the outer carrier are using non-segmented mLDP P-tunnels.
- 内载体和外载体均使用非分段mLDP P-隧道。
- The inner carrier is not aggregating the P-tunnels of the outer carrier but is content to carry each such P-tunnel in a single P-tunnel of its own.
- 内部载波不聚合外部载波的P隧道，而是满足于在其自身的单个P隧道中承载每个这样的P隧道。
The Carrier's Carrier scenario can be distinguished from the inter-AS scenario by the fact that in the former, the mLDP messages are being exchanged on VRF interfaces.
运营商的运营商场景与AS间场景的区别在于，在前者中，mLDP消息在VRF接口上交换。
[mLDP] defines a registry for "The LDP MP Opaque Value Element Basic Type". Two new code points have been assigned in this registry:
[mLDP]为“LDP MP不透明值元素基本类型”定义注册表。已在此注册表中分配了两个新代码点：
- Recursive Opaque Value: Type 7
- 递归不透明值：类型7
An opaque value of this type is itself a TLV that encodes an mLDP FEC type, as defined in [mLDP].
此类型的不透明值本身是编码mLDP FEC类型的TLV，如[mLDP]中所定义。
- VPN-Recursive Opaque Value: Type 8
- VPN递归不透明值：类型8
An opaque value of this type consists of an 8-octet Route Distinguisher as defined in [VPN], followed by a TLV that encodes an mLDP FEC type, as defined in [mLDP].
此类型的不透明值由[VPN]中定义的8个八位字节的路由识别器组成，然后是[mLDP]中定义的编码mLDP FEC类型的TLV。
The security considerations of [LDP] and [mLDP] apply.
[LDP]和[mLDP]的安全考虑适用。
Unauthorized modification of the FEC elements defined in this document can disrupt the creation of the multipoint LSPs or can cause the multipoint LSPs to pass through parts of the network where they are not supposed to go. This could potentially be used as part of an attack to illegitimately insert or intercept multicast traffic. However, since the FEC elements defined in this document are not inherently more vulnerable to this form of attack than are the previously defined FEC elements, this document does not add new security vulnerabilities.
对本文件中定义的FEC元件进行未经授权的修改可能会中断多点LSP的创建，或导致多点LSP通过网络中不应到达的部分。这可能被用作非法插入或拦截多播流量的攻击的一部分。但是，由于本文档中定义的FEC元素并不比之前定义的FEC元素更容易受到这种形式的攻击，因此本文档没有添加新的安全漏洞。
A description of general security issues for MPLS can be found in [RFC5920].
有关MPLS的一般安全问题的说明，请参见[RFC5920]。
The authors wish to thank Toerless Eckert for his contribution to this work.
作者希望感谢托利斯·埃克特对这项工作的贡献。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[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.
[mLDP]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[MVPN]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月。
[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月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
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 Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号邮编01719电子邮件：erosen@cisco.com
Maria Napierala AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 EMail: mnapierala@att.com
Maria Napierala AT&T实验室，新泽西州劳雷尔大道中城200号，邮编07748电子邮件：mnapierala@att.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: n.leymann@telekom.de
Nicolai Leymann德意志电信公司Winterfeldtstrasse 21柏林10781德国电子邮件：n。leymann@telekom.de