Internet Engineering Task Force (IETF) R. Aggarwal
Request for Comments: 6389 Juniper Networks
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 Orange
November 2011
Internet Engineering Task Force (IETF) R. Aggarwal
Request for Comments: 6389 Juniper Networks
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 Orange
November 2011
MPLS Upstream Label Assignment for LDP
用于LDP的MPLS上行标签分配
Abstract
摘要
This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs).
本文件描述了为标签分发协议（LDP）分发上游分配标签的程序。它还描述了如何使用这些过程来避免LDP点对多点（P2MP）标签交换路径（LSP）在LAN上的分支标签交换路由器（LSR）流量复制。
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/rfc6389.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6389.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. LDP Upstream Label Assignment Capability ........................3
4. Distributing Upstream-Assigned Labels in LDP ....................4
4.1. Procedures .................................................4
5. LDP Tunnel Identifier Exchange ..................................5
6. LDP Point-to-Multipoint LSPs on a LAN ...........................9
7. IANA Considerations ............................................11
7.1. LDP TLVs ..................................................11
7.2. Interface Type Identifiers ................................11
8. Security Considerations ........................................12
9. Acknowledgements ...............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. LDP Upstream Label Assignment Capability ........................3
4. Distributing Upstream-Assigned Labels in LDP ....................4
4.1. Procedures .................................................4
5. LDP Tunnel Identifier Exchange ..................................5
6. LDP Point-to-Multipoint LSPs on a LAN ...........................9
7. IANA Considerations ............................................11
7.1. LDP TLVs ..................................................11
7.2. Interface Type Identifiers ................................11
8. Security Considerations ........................................12
9. Acknowledgements ...............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
This document describes procedures for distributing upstream-assigned labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. These procedures follow the architecture for MPLS upstream label assignment described in [RFC5331].
本文件描述了为标签分配协议（LDP）[RFC5036]分配上游分配标签[RFC5331]的程序。这些过程遵循[RFC5331]中描述的MPLS上游标签分配架构。
This document describes extensions to LDP that a Label Switching Router (LSR) can use to advertise whether the LSR supports upstream label assignment to its neighboring LSRs.
本文档描述了LDP的扩展，标签交换路由器（LSR）可以使用LDP来公布LSR是否支持向其相邻LSR分配上游标签。
This document also describes extensions to LDP to distribute upstream-assigned labels.
本文档还描述了LDP的扩展，以分发上游分配的标签。
The usage of MPLS upstream label assignment using LDP to avoid branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs) [RFC6388] is also described.
还描述了使用LDP的MPLS上游标签分配的使用，以避免LDP点对多点（P2MP）标签交换路径（LSP）在LAN上的分支LSR业务复制[RFC6388]。
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]中所述进行解释。
According to [RFC5331], upstream-assigned label bindings MUST NOT be used unless it is known that a downstream LSR supports them. This implies that there MUST be a mechanism to enable an LSR to advertise to its LDP neighbor LSR(s) its support of upstream-assigned labels.
根据[RFC5331]，除非已知下游LSR支持上游分配的标签绑定，否则不得使用上游分配的标签绑定。这意味着必须有一种机制，使LSR能够向其LDP邻居LSR公布其对上游分配标签的支持。
A new Capability Parameter, the LDP Upstream Label Assignment Capability, is introduced to allow an LDP peer to exchange with its peers, its support of upstream label assignment. This parameter follows the format and procedures for exchanging Capability Parameters defined in [RFC5561].
引入了一个新的性能参数LDP上行标签分配能力，允许LDP节点与其对等节点进行交换，它支持上行标签分配。此参数遵循[RFC5561]中定义的交换能力参数的格式和过程。
Following is the format of the LDP Upstream Label Assignment Capability Parameter:
以下是LDP上游标签分配能力参数的格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Upstrm Lbl Ass Cap(0x0507)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Upstrm Lbl Ass Cap(0x0507)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
If an LSR includes the Upstream Label Assignment Capability in LDP Initialization messages, it implies that the LSR is capable of both distributing upstream-assigned label bindings and receiving upstream-assigned label bindings. The reserved bits MUST be set to zero on transmission and ignored on receipt. The Upstream Label Assignment Capability Parameter MUST be carried only in LDP Initialization messages and MUST be ignored if received in LDP Capability messages.
如果LSR在LDP初始化消息中包含上游标签分配功能，则意味着LSR能够分发上游分配的标签绑定和接收上游分配的标签绑定。传输时保留位必须设置为零，接收时忽略。上游标签分配能力参数只能在LDP初始化消息中携带，如果在LDP能力消息中收到，则必须忽略。
An optional LDP TLV, Upstream-Assigned Label Request TLV, is introduced. To request an upstream-assigned label, an LDP peer MUST include this TLV in a Label Request message.
介绍了一种可选的LDP TLV，即上行分配标签请求TLV。要请求上游分配的标签，LDP对等方必须在标签请求消息中包含此TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Upstrm-Ass Lbl Req (0x0205)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Upstrm-Ass Lbl Req (0x0205)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional LDP TLV, Upstream-Assigned Label TLV, is introduced to signal an upstream-assigned label. Upstream-Assigned Label TLVs are carried by the messages used to advertise, release, and withdraw upstream-assigned label mappings.
引入可选的LDP TLV，上游分配标签TLV，以向上游分配标签发送信号。上游分配的标签TLV由用于公布、发布和撤消上游分配的标签映射的消息携带。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Upstrm-Ass Label (0x0204) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Upstrm-Ass Label (0x0204) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label field is a 20-bit label value as specified in [RFC3032], represented as a 20-bit number in a 4-octet field as specified in Section 3.4.2.1 of RFC 5036 [RFC5036].
标签字段是[RFC3032]中规定的20位标签值，表示为RFC 5036[RFC5036]第3.4.2.1节中规定的4位八位组字段中的20位数字。
Procedures for Label Mapping, Label Request, Label Abort, Label Withdraw, and Label Release follow [RFC5036] other than the modifications pointed out in this section.
标签映射、标签请求、标签中止、标签撤销和标签发布程序遵循[RFC5036]，本节中指出的修改除外。
An LDP LSR MUST NOT distribute the Upstream-Assigned Label TLV to a neighboring LSR if the neighboring LSR has not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. An LDP LSR MUST NOT send the Upstream-Assigned Label Request TLV to a neighboring LSR if the neighboring LSR has not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages.
如果相邻LSR之前未在其LDP初始化消息中通告上游标签分配能力，则LDP LSR不得将上游分配的标签TLV分配给相邻LSR。如果相邻LSR之前未在其LDP初始化消息中通告上游标签分配能力，则LDP LSR不得向相邻LSR发送上游分配标签请求TLV。
As described in [RFC5331], the distribution of upstream-assigned labels is similar to either ordered LSP control or independent LSP control of the downstream-assigned labels.
如[RFC5331]所述，上游分配标签的分布类似于下游分配标签的有序LSP控制或独立LSP控制。
When the label distributed in a Label Mapping message is an upstream-assigned label, the Upstream-Assigned Label TLV MUST be included in the Label Mapping message. When an LSR receives a Label Mapping message with an Upstream-Assigned Label TLV and it does not recognize the TLV, it MUST generate a Notification message with a status code of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is unable to process the upstream label, it MUST generate a Notification message with a status code of "No Label Resources". If the Label Mapping message was generated in response to a Label Request message, the Label Request message MUST contain an Upstream-Assigned Label Request TLV. An LSR that generates an upstream-assigned label request to a neighbor LSR, for a given FEC, MUST NOT send a downstream label mapping to the neighbor LSR for that FEC unless it withdraws the upstream-assigned label binding. Similarly, if an LSR generates a downstream-assigned label request to a neighbor LSR, for a given FEC, it MUST NOT send an upstream label mapping to that LSR for that FEC, unless it aborts the downstream-assigned label request.
当标签映射消息中分发的标签是上游分配的标签时，上游分配的标签TLV必须包含在标签映射消息中。当LSR接收到带有上游分配标签TLV的标签映射消息且不识别TLV时，它必须生成状态代码为“未知TLV”[RFC5036]的通知消息。如果它确实识别TLV，但无法处理上游标签，则必须生成状态代码为“无标签资源”的通知消息。如果标签映射消息是响应标签请求消息生成的，则标签请求消息必须包含上游分配的标签请求TLV。对于给定的FEC，向邻居LSR生成上游分配标签请求的LSR不得向该FEC的邻居LSR发送下游标签映射，除非其撤销上游分配标签绑定。类似地，如果LSR为给定FEC向相邻LSR生成下游分配的标签请求，则它不得为该FEC向该LSR发送上游标签映射，除非它中止下游分配的标签请求。
The Upstream-Assigned Label TLV may be optionally included in Label Withdraw and Label Release messages that withdraw/release a particular upstream-assigned label binding.
上游分配的标签TLV可以选择性地包括在标签撤回和标签释放消息中，这些消息撤回/释放特定的上游分配的标签绑定。
As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit an MPLS packet, the top label of which (L) is upstream assigned, to its downstream neighbor LSR (Rd). In this case, the fact that L is upstream assigned is determined by Rd by the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels.
如[RFC5331]中所述，特定的上游LSR（Ru）可以向其下游邻居LSR（Rd）发送MPLS分组，其上标签（L）被上游分配。在这种情况下，L被上游分配的事实由Rd通过接收分组的隧道确定。Ru必须有一种机制来通知Rd，Ru将使用从Ru到Rd的特定隧道来传输具有上游分配的MPLS标签的MPLS数据包。
When LDP is used for upstream label assignment, the Interface ID TLV [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream assigned labels to Rd, Ru MUST include the Interface ID TLV in the Label
当LDP用于上游标签分配时，接口ID TLV[RFC3472]用于向隧道标识符发送信号。如果Ru使用IP或MPLS隧道将带有上游分配标签的MPLS数据包传输到Rd，Ru必须在标签中包含接口ID TLV
Mapping messages along with the Upstream-Assigned Label TLV. The IPv4/IPv6 Next/Previous Hop Address and the Logical Interface ID fields in the Interface ID TLV SHOULD be set to 0 by the sender and ignored by the receiver. The Length field indicates the total length of the TLV, i.e., 4 + the length of the Value field in octets. A Value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
将消息与上游分配的标签TLV一起映射。接口ID TLV中的IPv4/IPv6下一个/上一个跃点地址和逻辑接口ID字段应由发送方设置为0，并由接收方忽略。长度字段表示TLV的总长度，即4+值字段的长度（以八位字节为单位）。长度不是四的倍数的值字段必须加零，以便TLV与四个八位组对齐。
Hence the IPv4 Interface ID TLV has the following format:
因此，IPv4接口ID TLV具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Interface ID TLV has the following format:
IPv6接口ID TLV具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As shown in the above figures, the Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs are introduced to support RSVP - Traffic Engineering (RSVP-TE) P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels, and context labels. The sub-TLV value in the sub-TLV acts as the tunnel identifier.
如上图所示，接口ID TLV承载子TLV。引入了四个新的接口ID子TLV来支持RSVP-流量工程（RSVP-TE）P2MP LSP、LDP P2MP LSP、IP多播隧道和上下文标签。子TLV中的子TLV值用作隧道标识符。
The following sub-TLVs are introduced:
介绍了以下子TLV：
1. RSVP-TE P2MP LSP TLV (Type = 28)
1. RSVP-TE P2MP LSP TLV（类型=28）
The value of the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875].
TLV的值是RSVP-TE P2MP LSP会话对象[RFC4875]。
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 Interface ID TLV:
以下是在IPv4接口ID TLV中携带的RSVP-TE P2MP LSP TLV格式：
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 (0x1c) | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (0x1c) | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 Interface ID TLV:
以下是在IPv6接口ID TLV中携带的RSVP-TE P2MP LSP TLV格式：
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 (0x1c) | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (0x1c) | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control-plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP signaling messages.
该TLV识别RSVP-TE P2MP LSP。它允许Ru将标签为上游分配的“内部”LDP P2MP LSP隧道到具有叶<Rd1…Rdn>的“外部”RSVP-TE P2MP LSP上。RSVP-TE P2MP LSP IF_ID TLV允许Ru向<Rd1…Rdn>发送信号，说明内部LDP P2MP LSP与外部RSVP-TE P2MP LSP的绑定。内部P2MP LSP的Ru和<Rd1…Rdn>之间的控制平面信令使用目标LDP信令消息。
2. LDP P2MP LSP TLV (Type = 29)
2. LDP P2MP LSP TLV（类型=29）
The value of the TLV is the LDP P2MP FEC as defined in [RFC6388] and has to be set as per the procedures in [RFC6388]. Here is the format of the LDP P2MP FEC as defined in [RFC6388]:
TLV的值是[RFC6388]中定义的LDP P2MP FEC，必须按照[RFC6388]中的程序进行设置。以下是[RFC6388]中定义的LDP P2MP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Family MUST be set to IPv4, the Address Length MUST be set to 4, and the Root Node Address MUST be set to an IPv4 address when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV. The Address Family MUST be set to IPv6, the Address Length MUST be set to 16, and the Root Node Address MUST be set to an IPv6 address when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV.
当IPv4接口ID TLV中携带LDP P2MP LSP TLV时，地址族必须设置为IPv4，地址长度必须设置为4，根节点地址必须设置为IPv4地址。在IPv6接口ID TLV中携带LDP P2MP LSP TLV时，地址族必须设置为IPv6，地址长度必须设置为16，根节点地址必须设置为IPv6地址。
The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an inner LDP P2MP LSP, the label for which is upstream assigned, over an outer LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer LDP-P2MP LSP. The control-plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP signaling messages.
TLV值标识LDP P2MP LSP。它允许Ru在具有叶子<Rd1…Rdn>的外部LDP P2MP LSP上通过隧道传输内部LDP P2MP LSP，标签是上游分配的。LDP P2MP LSP IF_ID TLV允许Ru向<Rd1…Rdn>发送信号，说明内部LDP P2MP LSP与外部LDP-P2MP LSP的绑定。内部P2MP LSP的Ru和<Rd1…Rdn>之间的控制平面信令使用目标LDP信令消息。
3. IP Multicast Tunnel TLV (Type = 30)
3. IP多播隧道TLV（类型=30）
In this case, the TLV value is a <Source Address, Multicast Group Address> tuple. Source Address is the IP address of the root of the tunnel (i.e., Ru), and Multicast Group Address is the Multicast Group Address used by the tunnel. The addresses MUST be IPv4 addresses when the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV. The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV is included in the IPv6 Interface ID TLV.
在这种情况下，TLV值是<Source Address，Multicast Group Address>元组。源地址是隧道根（即Ru）的IP地址，多播组地址是隧道使用的多播组地址。当IP多播隧道TLV包含在IPv4接口ID TLV中时，地址必须是IPv4地址。当IP多播隧道TLV包含在IPv6接口ID TLV中时，地址必须是IPv6地址。
4. MPLS Context Label TLV (Type = 31)
4. MPLS上下文标签TLV（类型=31）
In this case, the TLV value is a <Source Address, MPLS Context Label> tuple. The Source Address belongs to Ru and the MPLS Context Label is an upstream-assigned label, assigned by Ru. The Source Address MUST be set to an IPv4 address when the MPLS Context Label TLV is carried in the IPv4 Interface ID TLV. The Source Address MUST be set to an IPv6 address when the MPLS Context Label TLV is carried in the IPv6 Interface ID TLV. This allows Ru to tunnel an inner LDP P2MP LSP, the label of which is upstream assigned, over an outer one-hop MPLS LSP, where the outer one-hop LSP has the following property:
在这种情况下，TLV值是一个<sourceaddress，MPLS Context Label>元组。源地址属于Ru，MPLS上下文标签是上游分配的标签，由Ru分配。在IPv4接口ID TLV中携带MPLS上下文标签TLV时，必须将源地址设置为IPv4地址。在IPv6接口ID TLV中携带MPLS上下文标签TLV时，必须将源地址设置为IPv6地址。这允许Ru在外部一跳MPLS LSP上隧道内部LDP P2MP LSP，其标签是上游分配的，其中外部一跳LSP具有以下属性：
o The label pushed by Ru for the outer MPLS LSP is an upstream-assigned context label, assigned by Ru. When <Rd1...Rdn> perform an MPLS label lookup on this label, a combination of this label and the incoming interface MUST be sufficient for <Rd1...Rdn> to uniquely determine Ru's context-specific label space to look up the next label on the stack. <Rd1...Rdn> MUST receive the data sent by Ru with the context-specific label assigned by Ru being the top label on the label stack.
o Ru为外部MPLS LSP推送的标签是上游分配的上下文标签，由Ru分配。当<Rd1…Rdn>在此标签上执行MPLS标签查找时，此标签和传入接口的组合必须足以让<Rd1…Rdn>唯一地确定Ru的上下文特定标签空间，以便查找堆栈上的下一个标签<Rd1…Rdn>必须接收Ru发送的数据，Ru分配的上下文特定标签是标签堆栈上的顶部标签。
Currently, the usage of the Context Label TLV is limited only to LDP P2MP LSPs on a LAN as specified in the next section. The Context Label TLV MUST NOT be used for any other purpose.
目前，上下文标签TLV的使用仅限于下一节中指定的LAN上的LDP P2MP LSP。上下文标签TLV不得用于任何其他目的。
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP, the above procedures assume that Ru has a priori knowledge of all the <Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled using RSVP-TE, Ru can obtain this information from RSVP-TE. However, in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP does not provide this information to Ru. In this scenario, the procedures by which Ru could acquire this information are outside the scope of this document.
注意，当外部P2MP LSP用RSVP-TE或MLDP发信号时，上述过程假设Ru具有所有<Rd1。。。Rdn>。在使用RSVP-TE发信号通知外部P2MP LSP的场景中，Ru可以从RSVP-TE获得该信息。然而，在使用MLDP向外部P2MP LSP发送信号的场景中，MLDP不向Ru提供此信息。在这种情况下，Ru获取此信息的过程超出了本文档的范围。
This section describes one application of upstream label assignment using LDP. Further applications are to be described in separate documents.
本节描述使用LDP的上行标签分配的一个应用。其他应用将在单独的文件中描述。
[RFC6388] describes how to setup P2MP LSPs using LDP. On a LAN the solution relies on "ingress replication". An LSR on a LAN, that is a branch LSR for a P2MP LSP (say Ru), sends a separate copy of a packet that it receives on the P2MP LSP to each of the downstream LSRs on the LAN (say <Rd1...Rdn>) that are adjacent to it in the P2MP LSP.
[RFC6388]介绍如何使用LDP设置P2MP LSP。在局域网上，该解决方案依赖于“入口复制”。LAN上的LSR，即P2MP LSP（如Ru）的分支LSR，将其在P2MP LSP上接收到的数据包的单独副本发送到LAN上与P2MP LSP中相邻的每个下游LSR（如<Rd1…Rdn>）。
It is desirable for Ru to send a single copy of the packet for the LDP P2MP LSP on the LAN, when there are multiple downstream routers
当存在多个下游路由器时，Ru希望在LAN上为LDP P2MP LSP发送分组的单个副本
on the LAN that are adjacent to Ru in that LDP P2MP LSP. This requires that each of <Rd1...Rdn> must be able to associate the label L, used by Ru to transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It is possible to achieve this using LDP upstream-assigned labels with the following procedures.
在该LDP P2MP LSP中与Ru相邻的LAN上。这要求每个<Rd1…Rdn>必须能够将Ru用于在LAN上传输P2MP LSP数据包的标签L与该P2MP LSP相关联。使用LDP上游分配的标签，通过以下步骤可以实现这一点。
Consider an LSR Rd that receives the LDP P2MP FEC [RFC6388] from its downstream LDP peer. Additionally, consider that the upstream interface to reach LSR Ru that is the next hop to the P2MP LSP root address (Pr) in the LDP P2MP FEC is a LAN interface (Li) and that Rd and Ru support upstream-assigned labels. In this case, instead of sending a Label Mapping message as described in [RFC6388], Rd sends a Label Request message to Ru. This Label Request message MUST contain an Upstream-Assigned Label Request TLV.
考虑LSR RD，它从其下游LDP对等点接收LDP PMP FEC [RCF638 ]。此外，考虑到达LSR RU的上行接口是下一跳到LDP PMP FEC中的PMP LSP根地址（PR）的一个LAN接口（李），RD和RU支持上游分配的标签。在这种情况下，Rd不发送[RFC6388]中所述的标签映射消息，而是向Ru发送标签请求消息。此标签请求消息必须包含上游分配的标签请求TLV。
On receiving this message, Ru sends back a Label Mapping message to Rd with an upstream-assigned label. This message also contains an Interface ID TLV with an MPLS Context Label sub-TLV, as described in the previous section, with the value of the MPLS label set to a value assigned by Ru on interface Li as specified in [RFC5331]. Processing of the Label Request and Label Mapping messages for LDP upstream-assigned labels is as described in Section 4.1. If Ru receives a Label Request for an upstream-assigned label for the same P2MP FEC from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send the same upstream-assigned label to each of <Rd1...Rdn>.
收到此消息后，Ru向Rd发回带有上游分配标签的标签映射消息。该消息还包含带有MPLS上下文标签子TLV的接口ID TLV，如前一节所述，MPLS标签的值设置为[RFC5331]中规定的Ru在接口Li上分配的值。LDP上游分配标签的标签请求和标签映射消息的处理如第4.1节所述。如果Ru从LAN上的多个下游LSR接收到针对同一P2MP FEC的上游分配标签的标签请求，<Rd1…Rdn>，则它必须向每个<Rd1…Rdn>发送相同的上游分配标签。
Ru transmits the MPLS packet using the procedures defined in [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains as the top label the context label assigned by Ru on the LAN interface, Li. The bottom label is the upstream label assigned by Ru to the LDP P2MP LSP. The top label is looked up in the context of the LAN interface (Li) by a downstream LSR on the LAN. This lookup enables the downstream LSR to determine the context-specific label space in which to look up the inner label.
Ru使用[RFC5331]和[RFC5332]中定义的过程传输MPLS数据包。Ru传输的MPLS数据包包含Ru在LAN接口Li上分配的上下文标签作为顶部标签。底部标签是Ru分配给LDP P2MP LSP的上游标签。顶部标签由LAN上的下游LSR在LAN接口（Li）的上下文中查找。此查找使下游LSR能够确定要在其中查找内部标签的特定于上下文的标签空间。
Note that <Rd1...Rdn> may have more than one equal-cost next hop on the LAN to reach Pr. It MAY be desirable for all of them to send the label request to the same upstream LSR and they MAY select one upstream LSR using the following procedure:
请注意，<Rd1…Rdn>在LAN上的下一跳可能有多个相同的成本以达到Pr。可能需要所有人将标签请求发送到相同的上游LSR，并且他们可以使用以下过程选择一个上游LSR：
1. The candidate upstream LSRs are numbered from lower to higher IP address.
1. 候选上游LSR的IP地址从低到高依次编号。
2. The following hash is performed: H = (Sum Opaque value) modulo N, where N is the number of candidate upstream LSRs. The Opaque value is defined in [RFC6388] and comprises the P2MP LSP identifier.
2. 执行以下哈希：H=（总和不透明值）模N，其中N是候选上游LSR的数量。不透明值在[RFC6388]中定义，包括P2MP LSP标识符。
3. The selected upstream LSR U is the LSR that has the number H.
3. 所选上游LSR U是具有数字H的LSR。
This allows for load balancing of a set of LSPs among a set of candidate upstream LSRs, while ensuring that on a LAN interface, a single upstream LSR is selected. It is also to be noted that the procedures in this section can still be used by Rd and Ru if other LSRs on the LAN do not support upstream label assignment. Ingress replication and downstream label assignment will continue to be used for LSRs that do not support upstream label assignment.
这允许在一组候选上游LSR之间对一组LSP进行负载平衡，同时确保在LAN接口上选择单个上游LSR。还应注意，如果LAN上的其他LSR不支持上游标签分配，则Rd和Ru仍可使用本节中的程序。入口复制和下游标签分配将继续用于不支持上游标签分配的LSR。
IANA maintains a registry of LDP TLVs at the registry "Label Distribution Protocol" in the sub-registry called "TLV Type Name Space".
IANA在名为“TLV类型名称空间”的子注册表中的注册表“标签分发协议”中维护LDP TLV的注册表。
This document defines a new LDP Upstream Label Assignment Capability TLV (Section 3). IANA has assigned the value 0x0507 to this TLV.
本文件定义了新的LDP上游标签分配能力TLV（第3节）。IANA已将值0x0507分配给该TLV。
This document defines a new LDP Upstream-Assigned Label TLV (Section 4). IANA has assigned the type value of 0x204 to this TLV.
本文件定义了新的LDP上游分配标签TLV（第4节）。IANA已将类型值0x204分配给此TLV。
This document defines a new LDP Upstream-Assigned Label Request TLV (Section 4). IANA has assigned the type value of 0x205 to this TLV.
本文件定义了新的LDP上游分配标签请求TLV（第4节）。IANA已将类型值0x205分配给该TLV。
[RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top-level TLVs can carry sub-TLVs dependent on the interface type. These sub-TLVs are assigned "Interface ID Types". IANA maintains a registry of Interface ID Types for use in GMPLS in the registry "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub-registry "Interface_ID Types". IANA has made the corresponding allocations from this registry as follows:
[RFC3472]定义LDP接口ID IPv4和IPv6 TLV。这些顶级TLV可以承载子TLV，具体取决于接口类型。这些子TLV被分配“接口ID类型”。IANA在注册表“通用多协议标签交换（GMPLS）信令参数”和子注册表“接口ID类型”中维护一个接口ID类型注册表，供GMPLS使用。IANA已从该注册表中进行了相应的分配，如下所示：
- RSVP-TE P2MP LSP TLV (value 28)
- RSVP-TE P2MP LSP TLV（值28）
- LDP P2MP LSP TLV (value 29)
- LDP P2MP LSP TLV（值29）
- IP Multicast Tunnel TLV (value 30)
- IP多播隧道TLV（值30）
- MPLS Context Label TLV (value 31)
- MPLS上下文标签TLV（值31）
The security considerations discussed in [RFC5036], [RFC5331], and [RFC5332] apply to this document.
[RFC5036]、[RFC5331]和[RFC5332]中讨论的安全注意事项适用于本文档。
More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks" [RFC5920].
“MPLS和GMPLS网络安全框架”[RFC5920]中详细讨论了与MPLS和GMPLS相关的安全问题，包括安全威胁、相关防御技术以及检测和报告机制。
Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thomas Morin for their comments. The hashing algorithm used on LAN interfaces is taken from [RFC6388]. Thanks to Loa Andersson, Adrian Farrel, and Eric Rosen for their comments and review.
感谢亚科夫·雷克特的贡献。感谢Ina Minei和Thomas Morin的评论。LAN接口上使用的哈希算法取自[RFC6388]。感谢Loa Andersson、Adrian Farrel和Eric Rosen的评论和评论。
[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月。
[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月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[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月。
[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月。
[RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood Smith，P.，Ed.，和L.Berger，Ed.，“基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
Author's Address
作者地址
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Phone: +1-408-936-2720 EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089电话：+1-408-936-2720电子邮件：raggarwa_1@yahoo.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：jeanlouis。leroux@orange-ftgroup.com