Internet Engineering Task Force (IETF) M. Napierala
Request for Comments: 7060 AT&T
Category: Standards Track E. Rosen
ISSN: 2070-1721 IJ. Wijnands
Cisco Systems, Inc.
November 2013
Internet Engineering Task Force (IETF) M. Napierala
Request for Comments: 7060 AT&T
Category: Standards Track E. Rosen
ISSN: 2070-1721 IJ. Wijnands
Cisco Systems, Inc.
November 2013
Using LDP Multipoint Extensions on Targeted LDP Sessions
在目标LDP会话上使用LDP多点扩展
Abstract
摘要
Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.
标签分发协议（LDP）可用于建立点对多点（P2MP）和多点对多点（MP2MP）标签交换路径。然而，LDP的多点扩展规范假定LDP会话的两个端点直接连接。LDP基本规范允许LDP会话的两个端点不直接连接的情况；这种会议被称为“有针对性的自民党”会议。本文档提供了在目标LDP会话上使用LDP多点扩展的规范。
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/rfc7060.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7060.
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 ....................................................2
2. Targeted mLDP and the Upstream LSR ..............................3
2.1. Selecting the Upstream LSR .................................3
2.2. Sending Data from U to D ...................................4
3. Applicability of Targeted mLDP ..................................4
4. LDP Capabilities ................................................5
5. Targeted mLDP with Unicast Replication ..........................5
6. Targeted mLDP with Multicast Tunneling ..........................6
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. Normative References ............................................8
1. Introduction ....................................................2
2. Targeted mLDP and the Upstream LSR ..............................3
2.1. Selecting the Upstream LSR .................................3
2.2. Sending Data from U to D ...................................4
3. Applicability of Targeted mLDP ..................................4
4. LDP Capabilities ................................................5
5. Targeted mLDP with Unicast Replication ..........................5
6. Targeted mLDP with Multicast Tunneling ..........................6
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. Normative References ............................................8
Label Distribution Protocol (LDP) extensions for setting up Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This set of extensions is generally known as "Multipoint LDP" (mLDP).
[mLDP]中规定了用于设置点对多点（P2MP）标签交换路径（LSP）和多点对多点（MP2MP）LSP的标签分发协议（LDP）扩展。这组扩展通常称为“多点LDP”（mLDP）。
A pair of Label Switched Routers (LSRs) that are the endpoints of an LDP session are considered to be "LDP peers". When a pair of LDP peers are "directly connected" (e.g., they are connected by a layer 2 medium or are otherwise considered to be neighbors by the network's interior routing protocol), the LDP session is said to be a "directly connected" LDP session. When the pair of LDP peers are not directly connected, the session between them is said to be a "Targeted" LDP session.
作为LDP会话的端点的一对标签交换路由器（LSR）被认为是“LDP对等点”。当一对LDP对等点“直接连接”（例如，它们通过第2层介质连接，或者被网络的内部路由协议视为邻居）时，LDP会话被称为“直接连接”的LDP会话。当这对LDP对等点不直接连接时，它们之间的会话称为“目标”LDP会话。
The base specification for mLDP does not explicitly cover the case where the LDP multipoint extensions are used over a Targeted LDP session. This document provides that specification.
mLDP的基本规范没有明确涵盖在目标LDP会话上使用LDP多点扩展的情况。本文件提供了该规范。
We will use the term "Multipoint" to mean "either P2MP or MP2MP".
我们将使用术语“多点”来表示“P2MP或MP2MP”。
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]中所述进行解释。
In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that is an ordered pair of the form <root, opaque value>. The first element of the ordered pair is the IP address of the MP-LSP's "root node". The second element of the ordered pair is an identifier that is unique in the context of the root node.
在mLDP中，多点LSP（MP-LSP）具有唯一标识符，该标识符是一对有序的<root，不透明值>。有序对的第一个元素是MP-LSP的“根节点”的IP地址。有序对的第二个元素是在根节点上下文中唯一的标识符。
If LSR D is setting up the MP-LSP <R, X>, D must determine the "upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>, U, is defined to be the "next hop" on D's path to R, and "next hop" is tacitly assumed to mean "IGP next hop". It is thus assumed that there is a direct LDP session between D and U. In this specification, we extend the notion of "upstream LSR" to cover the following cases:
如果LSR D正在设置MP-LSP<R，X>，则D必须确定<R，X>的“上游LSR”。在[mLDP]中，<R，X>，U的上游LSR被定义为D到R的路径上的“下一跳”，并且“下一跳”被默认为意味着“IGP下一跳”。因此，假设D和U之间存在直接LDP会话。在本规范中，我们扩展了“上游LSR”的概念，以涵盖以下情况：
- U is the "BGP next hop" on D's path to R, where U and D are not necessarily IGP neighbors, and where there is a Targeted LDP session between U and D. In this case, we allow D to select U as the "upstream LSR" for <R,X>.
- U是D到R的路径上的“BGP下一跳”，其中U和D不一定是IGP邻居，并且U和D之间存在目标LDP会话。在这种情况下，我们允许D选择U作为<R，X>的“上游LSR”。
- If the "next-hop interface" on D's path to R is an RSVP Traffic Engineering (RSVP-TE) P2P tunnel whose remote endpoint is U, and if there is known to be an RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP session between U and D, then we allow D to select U as the "upstream LSR" for <R,X>. This is useful when D and U are part of a network area that is fully meshed via RSVP-TE P2P tunnels.
- 如果D到R的路径上的“下一跳接口”是一个远程端点为U的RSVP流量工程（RSVP-TE）P2P隧道，并且如果已知有一个从U到D的RSVP-TE P2P隧道，并且如果U和D之间有一个目标LDP会话，那么我们允许D选择U作为<R，X>的“上游LSR”。当D和U是通过RSVP-TE P2P隧道完全网格化的网络区域的一部分时，这非常有用。
The particular method used to select an "upstream LSR" is determined by the Service Provider (SP) and must be made known a priori (i.e., by provisioning) to all the LSRs involved.
用于选择“上游LSR”的特定方法由服务提供商（SP）确定，并且必须事先（即通过供应）告知所有相关LSR。
Other methods than the two specified above MAY be used; however, the specification of other methods is outside the scope of this document.
可使用上述两种方法以外的其他方法；但是，其他方法的规范不在本文件的范围内。
By using Targeted mLDP, we can construct an MP-LSP <R,X> containing an LSR U, where U has one or more downstream LSR neighbors (D1, ..., Dn) to which it is not directly connected. In order for a data packet to travel along this MP-LSP, U must have some way of transmitting the packet to D1, ..., Dn. We will cover two methods of transmission:
通过使用目标mLDP，我们可以构造一个包含LSR U的MP-LSP<R，X>，其中，U有一个或多个下游LSR邻居（D1，…，Dn），它没有直接连接到该邻居。为了使数据包沿着MP-LSP传输，U必须有某种方式将数据包传输到D1，…，Dn。我们将介绍两种传输方法：
- Unicast Replication
- 单播复制
In this method, U creates n copies of the packet and unicasts each copy to exactly one of D1, ..., Dn.
在该方法中，U创建数据包的n个副本，并将每个副本单播到D1、…、Dn中的一个。
- Multicast Tunneling
- 多播隧道
In this method, U becomes the root node of a multicast tunnel, with D1, ..., Dn as leaf nodes. When a packet traveling along the MP-LSP <R,X> arrives at U, U transmits it through the multicast tunnel, and as a result it arrives at D1, ..., Dn.
在这种方法中，U成为多播隧道的根节点，D1，…，Dn作为叶节点。当沿着MP-LSP<R，X>移动的数据包到达U时，U通过多播隧道传输它，结果它到达D1，…，Dn。
When this method is used, it may be desirable to carry traffic of multiple MP-LSPs through a single multicast tunnel. We specify procedures that allow for the proper demultiplexing of the MP-LSPs at the leaf nodes of the multicast tunnel. We do not assume that all the leaf nodes of the tunnel are on all the MP-LSPs traveling through the tunnel; thus, some of the tunnel leaf nodes may need to discard some of the packets received through the tunnel. For example, suppose MP-LSP <R1,X1> contains node U with downstream LSRs D1 and D2, while MP-LSP <R2,X2> contains node U with downstream LSRs D2 and D3. Suppose also that there is a multicast tunnel with U as root and with D1, D2, and D3 as leaf nodes. U can aggregate both MP-LSPs in this one tunnel. However, D1 will have to discard packets that are traveling on <R2,X1>, while D3 will have to discard packets that are traveling on <R1,X2>.
当使用此方法时，可能希望通过单个多播隧道承载多个MP LSP的通信量。我们指定了允许在多播隧道的叶节点上正确解复用MP LSP的过程。我们不假设隧道的所有叶节点都位于通过隧道的所有MP LSP上；因此，一些隧道叶节点可能需要丢弃通过隧道接收的一些分组。例如，假设MP-LSP<R1，X1>包含具有下游LSR D1和D2的节点U，而MP-LSP<R2，X2>包含具有下游LSR D2和D3的节点U。还假设存在一个多播隧道，U作为根节点，D1、D2和D3作为叶节点。你可以在这个隧道中聚合两个MP LSP。但是，D1必须丢弃在<R2，X1>上移动的数据包，而D3必须丢弃在<R1，X2>上移动的数据包。
When LSR D is setting up MP-LSP <R,X>, it MUST NOT use Targeted mLDP unless D implements a procedure that can select an LSR U that is a Targeted mLDP peer of D as the "upstream LSR" for <R,X>. See Section 2.1.
当LSR D设置MP-LSP<R，X>时，它不得使用目标mLDP，除非D执行一个程序，该程序可以选择作为D的目标mLDP对等点的LSR U作为<R，X>的“上游LSR”。见第2.1节。
Whether D uses Targeted mLDP when this condition holds is determined by provisioning or by other methods that are outside the scope of this specification.
当此条件成立时，D是否使用目标mLDP取决于供应或本规范范围之外的其他方法。
When Targeted mLDP is used, the choice between unicast replication and multicast tunneling is determined by provisioning or by other methods that are outside the scope of this specification. It is presupposed that all nodes will have a priori knowledge of whether to use unicast replication or to use multicast tunneling. If the latter, it is presupposed that all nodes will have a priori knowledge of the type of multicast tunneling to use.
使用目标mLDP时，单播复制和多播隧道之间的选择由供应或本规范范围之外的其他方法决定。假设所有节点都具有使用单播复制还是使用多播隧道的先验知识。如果是后者，则假定所有节点都具有要使用的多播隧道类型的先验知识。
Per [mLDP], any LSR that needs to set up an MP-LSP must support the procedures of [LDP-CAP], and in particular must send and receive the P2MP Capability and/or the MP2MP Capability. This specification does not define any new capabilities; the advertisement of the P2MP and/or MP2MP Capabilities on a Targeted LDP session means that the advertising LSR is capable of following the procedures set forth in this document.
根据[mLDP]，任何需要建立MP-LSP的LSR必须支持[LDP-CAP]的程序，特别是必须发送和接收P2MP能力和/或MP2MP能力。本规范未定义任何新功能；在目标LDP会话上公布P2MP和/或MP2MP功能意味着公布LSR能够遵循本文件中规定的程序。
Some of the procedures described in this document require the use of upstream-assigned labels [LDP-UP]. In order to use upstream-assigned labels as part of Targeted mLDP, an LSR must advertise the LDP Upstream-Assigned Label Capability [LDP-UP] on the Targeted LDP session.
本文件中描述的一些程序要求使用上游分配标签[LDP-UP]。为了将上游分配标签用作目标mLDP的一部分，LSR必须在目标LDP会话上公布LDP上游分配标签能力[LDP-UP]。
When unicast replication is used, the mLDP procedures are exactly the same as described in [mLDP], with the following exception. If LSR D is setting up MP-LSP <R,X>, its "upstream LSR" is selected according to the procedures of Section 2.1, and is not necessarily the "IGP next hop" on D's path to R.
使用单播复制时，mLDP过程与[mLDP]中所述完全相同，但以下情况除外。如果LSR D正在设置MP-LSP<R，X>，则其“上游LSR”是根据第2.1节的程序选择的，不一定是D到R的路径上的“IGP下一跳”。
Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP <R,X>, and that LSR U is the upstream LSR on each of their paths to R. D1 and D2 each binds a label to <R,X> and each uses a Label Mapping message to inform U of the label binding. Suppose D1 has assigned label L1 to <R,X> and D2 has assigned label L2 to <R,X>. (Note that L1 and L2 could have the same value or different values; D1 and D2 do not coordinate their label assignments.) When U has a packet to transmit on the MP-LSP <R,X>, it makes a copy of the packet, pushes on label L1, and unicasts the resulting packet to D1. It also makes a second copy of the packet, pushes on label L2, and then unicasts the resulting packet to D2.
假设LSR D1和D2都在设置P2MP MP-LSP<R，X>，并且LSR U是它们到R的每个路径上的上游LSR。D1和D2各自将标签绑定到<R，X>，并且各自使用标签映射消息通知U标签绑定。假设D1将标签L1分配给<R，X>，D2将标签L2分配给<R，X>。（注意，L1和L2可以具有相同的值或不同的值；D1和D2不协调它们的标签分配。）当U在MP-LSP<R，X>上有一个数据包要传输时，它复制该数据包，按下标签L1，并将结果数据包单播给D1。它还生成数据包的第二个副本，按下标签L2，然后将生成的数据包单播到D2。
This procedure also works when the MP-LSP <R,X> is an MP2MP LSP.
Suppose that in addition to labels L1 and L2 described above, U has
assigned label L3 for <R,X> traffic received from D1 and label L4 for
<R,X> traffic received from D2. When U processes a packet with label
This procedure also works when the MP-LSP <R,X> is an MP2MP LSP.
Suppose that in addition to labels L1 and L2 described above, U has
assigned label L3 for <R,X> traffic received from D1 and label L4 for
<R,X> traffic received from D2. When U processes a packet with label
L3 at the top of its label stack, it knows the packet is from D1, so U sends a unicast copy of the packet to D2, after swapping L3 for L2. U does not send a copy back to D1.
L3在其标签堆栈的顶部，它知道数据包来自D1，因此U在将L3交换为L2后，向D2发送数据包的单播副本。U不向D1发送副本。
Note that all labels used in this procedure are downstream-assigned labels.
请注意，此过程中使用的所有标签都是下游指定的标签。
The method of unicast is a local matter, outside the scope of this specification. The only requirement is that D1 will receive the copy of the packet carrying label L1 and that D1 will process the packet by looking up label L1. (And similarly, D2 must receive the copy of the packet carrying label L2 and must process the packet by looking up label L2.)
单播方法是局部问题，不在本规范的范围内。唯一的要求是D1将接收携带标签L1的包的副本，并且D1将通过查找标签L1来处理该包。（类似地，D2必须接收携带标签L2的包的副本，并且必须通过查找标签L2来处理该包。）
Note that if the method of unicast is MPLS, U will need to push another label on each copy of the packet before transmitting it. This label needs to ensure that delivery of the packet to the appropriate LSR, D1 or D2. Use of penultimate-hop popping for that label is perfectly legitimate.
注意，如果单播的方法是MPLS，则在发送数据包之前，U需要在数据包的每个副本上推送另一个标签。此标签需要确保将数据包传送到适当的LSR、D1或D2。使用倒数第二跳弹出标签是完全合法的。
Suppose that LSRs D1 and D2 are both setting up MP-LSP <R,X> and that LSR U is the upstream LSR on each of their paths to R. Since multicast tunneling is being used, when U has a packet to send on this MP-LSP, it does not necessarily send two copies, one to D1 and one to D2. It may send only one copy of the packet, which will get replicated somewhere downstream in the multicast tunnel. Therefore, the label that gets bound to the MP-LSP must be an upstream-assigned label assigned by U. This requires a change from the procedures of [mLDP]. D1 and D2 do not send Label Mapping messages to U; instead, they send Label Request messages to U, following the procedures of Section 4 of [LDP-UP], asking U to assign a label to the MP-LSP <R,X>. U responds with a Label Mapping message containing an upstream-assigned label L (using the procedures specified in [LDP-UP]). As part of the same Label Mapping message, U also sends an Interface TLV (as specified in [LDP-UP]) identifying the multicast tunnel in which data on the MP-LSP will be carried. When U transmits a packet on this tunnel, it first pushes on the upstream-assigned label L and then pushes on the label that corresponds to the multicast tunnel.
假设LSR D1和D2都在设置MP-LSP<R，X>，并且LSR U是它们到R的每个路径上的上游LSR。由于正在使用多播隧道，当U在该MP-LSP上有一个数据包要发送时，它不一定发送两个副本，一个到D1，一个到D2。它可能只发送数据包的一个副本，该副本将被复制到多播隧道的下游某处。因此，绑定到MP-LSP的标签必须是U分配的上游分配标签。这需要更改[mLDP]的程序。D1和D2不向U发送标签映射消息；相反，他们按照[LDP-UP]第4节的程序向U发送标签请求消息，要求U为MP-LSP<R，X>分配标签。U使用包含上游分配的标签L的标签映射消息进行响应（使用[LDP-UP]中指定的程序）。作为同一标签映射消息的一部分，U还发送一个接口TLV（如[LDP-UP]中指定的），该接口TLV标识将在其中承载MP-LSP上的数据的多播隧道。当U在此隧道上传输数据包时，它首先推送上游分配的标签L，然后推送对应于多播隧道的标签。
If the numerical value L of the upstream-assigned label is the value 3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the specified multicast tunnel will carry only the specified MP-LSP. That is, aggregation of multiple MP-LSPs into a single multicast
如果上游分配标签的数值L是值3，在[LDP]和[RFC3032]中定义为“隐式NULL”，则指定的多播隧道将只携带指定的MP-LSP。即，将多个MP LSP聚合为单个多播
tunnel is not being done. In this case, no upstream-assigned label is pushed onto a packet that is transmitted through the multicast tunnel.
隧道尚未完工。在这种情况下，没有上游分配的标签被推送到通过多播隧道传输的分组上。
Various types of multicast tunnel may be used. The choice of tunnel type is determined by provisioning, or by some other method that is outside the scope of this document. [LDP-UP] specifies encodings allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well as other types of multicast tunnel.
可以使用各种类型的多播隧道。隧道类型的选择由设置或本文档范围之外的其他方法决定。[LDP-UP]指定允许U识别mLDP MP-LSP和RSVP-TE P2MP LSP以及其他类型的多播隧道的编码。
Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are outside the scope of this document.
通过P2MP或MP2MP LSP隧道MP2MP LSP的程序不在本文件范围内。
If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, when U transmits a packet on the MP-LSP <R,X>, the upstream-assigned label L will be the second label in the label stack. Penultimate-hop popping MUST NOT be done, because the top label provides the context in which the second label is to be interpreted. See [RFC5331].
如果多播隧道是mLDP MP-LSP或RSVP-TE P2MP LSP，则当U在MP-LSP<R，X>上传输数据包时，上游分配的标签L将是标签堆栈中的第二个标签。倒数第二跳弹出不能进行，因为顶部标签提供了解释第二个标签的上下文。参见[RFC5331]。
When LSR U uses these procedures to inform LSR D that a particular MP-LSP is being carried in a particular multicast tunnel, U and D MUST take appropriate steps to ensure that the packets U sends into this tunnel will be received by D. The exact steps to take depend on the tunnel type. As long as U is D's upstream LSR for any MP-LSP that has been assigned to this tunnel, D must remain joined to the tunnel.
当LSR U使用这些过程通知LSR D特定的MP-LSP正在特定的多播隧道中传输时，U和D必须采取适当的步骤，以确保U发送到该隧道中的数据包将被D接收。要采取的确切步骤取决于隧道类型。只要U是分配给该隧道的任何MP-LSP的D上游LSR，D必须保持与隧道的连接。
Note that U MAY assign the same multicast tunnel for multiple different MP-LSPs. However, U MUST assign a distinct upstream-assigned label to each MP-LSP. This allows the packets traveling through the tunnel to be demultiplexed into the proper MP-LSPs.
注意，U可以为多个不同的MP LSP分配相同的多播隧道。但是，U必须为每个MP-LSP分配一个不同的上游分配标签。这允许通过隧道的数据包被解复用到适当的MP LSP中。
If U has an MP-LSP <R1,X1> with downstream LSRs D1 and D2, and an MP-LSP <R2,X2> with downstream LSRs D2 and D3, U may assign both MP-LSPs to the same multicast tunnel. In this case, D3 will receive packets traveling on <R1,X1>. However, the upstream-assigned label carried by those packets will not be recognized by D3, hence D3 will discard those packets. Similarly, D1 will discard the <R2,X2> packets.
如果U具有具有下游lsr D1和D2的MP-LSP<R1，X1>，以及具有下游lsr D2和D3的MP-LSP<R2，X2>，则U可以将两个MP-LSP分配给相同的多播隧道。在这种情况下，D3将接收在<R1，X1>上传输的数据包。然而，这些包携带的上游分配标签将不会被D3识别，因此D3将丢弃这些包。类似地，D1将丢弃<R2，X2>数据包。
This document does not specify any rules for deciding whether to aggregate two or more MP-LSPs into a single multicast tunnel. Such rules are outside the scope of this document.
本文档未指定任何规则来决定是否将两个或多个MP LSP聚合到单个多播隧道中。此类规则不在本文件的范围内。
Except for the procedures explicitly detailed in this document, the procedures of [mLDP] and [LDP-UP] apply unchanged.
除本文件中明确详述的程序外，[mLDP]和[LDP-UP]的程序不作更改。
This document raises no new security considerations beyond those discussed in [LDP], [LDP-UP], and [RFC5331].
除[LDP]、[LDP-UP]和[RFC5331]中讨论的内容外，本文件未提出任何新的安全注意事项。
The authors wish to thank Lizhong Jin and Lizhen Bin for their comments.
作者希望感谢金立中和李振斌的评论。
[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月。
[LDP-CAP] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[LDP-CAP]Thomas，B.，Raza，K.，Aggarwal，S.，Aggarwal，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[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月。
[LDP-UP] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011.
阿加瓦尔，R.和JL。Le Roux，“LDP的MPLS上游标签分配”，RFC 6389，2011年11月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
Authors' Addresses
作者地址
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
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 USA
Eric C.Rosen Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时
EMail: ice@cisco.com
EMail: ice@cisco.com