Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 8338 VMware
Updates: 7385 S. Sivabalan, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2018
Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 8338 VMware
Updates: 7385 S. Sivabalan, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2018
Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP
使用LDP发送根发起的点对多点伪线
Abstract
摘要
This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.
本文档指定了一种使用LDP向点对多点（P2MP）伪线（PW）树发送信号的机制。这种机制适用于任何需要通过IP或启用MPLS的PSN进行P2MP连接的第2层VPN服务。通过提议的机制建立的P2MP PW是根启动的。本文档通过将保留值0xFF重新指定为通配符传输隧道类型来更新RFC 7385。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8338.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8338.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PW Ingress-to-Egress Incompatibility Issues . . . . . . . 6
3.2. P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. P2MP PW Upstream FEC Element . . . . . . . . . . . . 7
3.2.2. P2P PW Downstream FEC Element . . . . . . . . . . . . 11
3.3. Typed Wildcard FEC Format for a New FEC . . . . . . . . . 11
3.4. Group ID Usage . . . . . . . . . . . . . . . . . . . . . 12
3.5. Generic Label TLV . . . . . . . . . . . . . . . . . . . . 12
4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . 12
5. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 15
7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . 15
7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . 15
7.4. Selective Tree Interface Parameter Sub-TLV Type . . . . . 15
7.5. Wildcard PMSI Tunnel Type . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PW Ingress-to-Egress Incompatibility Issues . . . . . . . 6
3.2. P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. P2MP PW Upstream FEC Element . . . . . . . . . . . . 7
3.2.2. P2P PW Downstream FEC Element . . . . . . . . . . . . 11
3.3. Typed Wildcard FEC Format for a New FEC . . . . . . . . . 11
3.4. Group ID Usage . . . . . . . . . . . . . . . . . . . . . 12
3.5. Generic Label TLV . . . . . . . . . . . . . . . . . . . . 12
4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . 12
5. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 15
7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . 15
7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . 15
7.4. Selective Tree Interface Parameter Sub-TLV Type . . . . . 15
7.5. Wildcard PMSI Tunnel Type . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over PSN. A major difference between a Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is intended for bidirectional service whereas the latter is intended for both unidirectional and, optionally, bidirectional service. Requirements for P2MP PWs are described in [RFC7338]. P2MP PWs can be constructed as either Single Segment Pseudowires (P2MP SS-PWs) or Multi-Segment Pseudowires (P2MP MS-PWs) as mentioned in [RFC7338]. P2MP MS-PW is outside the scope of this document. A reference model or a P2MP PW is depicted in Figure 1. A transport Label Switched Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP Traffic Engineering (TE) tunnel established via RSVP-TE [RFC4875] or P2MP LSP established via Multipoint LDP (mLDP) [RFC6388]) spanning from the Root PE (Provider Edge) to the Leaf
点对多点（P2MP）伪线（PW）模拟单向P2MP电信服务的基本属性，如PSN上的P2MP ATM。[RFC3985]中概述的点对点（P2P）PW与P2MP PW之间的主要区别在于前者用于双向服务，而后者用于单向和可选的双向服务。[RFC7338]中描述了P2MP PWs的要求。P2MP PW可以构造为[RFC7338]中提到的单段伪线（P2MP SS PW）或多段伪线（P2MP MS PW）。P2MP MS-PW不在本文件范围内。参考模型或P2MP PW如图1所示。与P2MP SS-PW相关联的传输标签交换路径（LSP）应该是一个P2MP MPLS LSP（即，通过RSVP-TE[RFC4875]建立的P2MP流量工程（TE）隧道或通过多点LDP（mLDP）[RFC6388]建立的P2MP LSP），从根PE（提供者边缘）到叶
PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel or P2MP LSP setup using mLDP originating from PE1 and terminating at PE2, PE3, and PE4.
P2MP SS-PW树的PE。例如，在图1中，PW1可以使用源自PE1并终止于PE2、PE3和PE4的mLDP与P2MP TE隧道或P2MP LSP设置相关联。
|<--------------P2MP PW---------------->|
Native | | Native
Service | |<--PSN1->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +-----+ +------+ +------+ |
| | | | P1 |=========|T-PE2 |AC3 | +---+
| | | | .......PW1.........>|-------->|CE3|
| |T-PE1|=========| . |=========| | | +---+
| | .......PW1........ | +------+ |
| | . |=========| . | +------+ |
| | . | | . |=========|T-PE3 |AC4 | +---+
+---+ |AC1 | . | | .......PW1.........>|-------->|CE4|
|CE1|------->|... | | |=========| | | +---+
+---+ | | . | +------+ +------+ |
| | . | +------+ +------+ |
| | . |=========| P2 |=========|T-PE4 |AC5 | +---+
| | .......PW1..............PW1.........>|-------->|CE5|
| | |=========| |=========| | | +---+
| +-----+ +------+ +------+ |
|<--------------P2MP PW---------------->|
Native | | Native
Service | |<--PSN1->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +-----+ +------+ +------+ |
| | | | P1 |=========|T-PE2 |AC3 | +---+
| | | | .......PW1.........>|-------->|CE3|
| |T-PE1|=========| . |=========| | | +---+
| | .......PW1........ | +------+ |
| | . |=========| . | +------+ |
| | . | | . |=========|T-PE3 |AC4 | +---+
+---+ |AC1 | . | | .......PW1.........>|-------->|CE4|
|CE1|------->|... | | |=========| | | +---+
+---+ | | . | +------+ +------+ |
| | . | +------+ +------+ |
| | . |=========| P2 |=========|T-PE4 |AC5 | +---+
| | .......PW1..............PW1.........>|-------->|CE5|
| | |=========| |=========| | | +---+
| +-----+ +------+ +------+ |
Figure 1: P2MP PW
图1:P2MP PW
Mechanisms for establishing a P2P SS-PW using LDP are described in [RFC8077]. This document specifies a method of signaling P2MP PW using LDP. In particular, this document defines a new Forwarding Equivalence Class (FEC), TLVs, parameters, and status codes to facilitate LDP signaling and maintaining P2MP PWs.
[RFC8077]中描述了使用LDP建立P2P SS-PW的机制。本文件规定了使用LDP发送P2MP PW信号的方法。特别是，本文件定义了新的转发等价类（FEC）、TLV、参数和状态码，以促进LDP信令和维护P2MP PWs。
As outlined in [RFC7338], even though the traffic flow from a Root PE (R-PE) to Leaf PE(s) (L-PEs) is P2MP in nature, it may be desirable for any L-PE to send unidirectional P2P traffic destined only to the R-PE. The proposed mechanism takes such an option into consideration.
如[RFC7338]中所述，即使从根PE（R-PE）到叶PE（s）（L-PE）的流量本质上是P2MP，任何L-PE都可能希望只向R-PE发送单向P2P流量。拟议的机制考虑了这一选择。
The P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS packets carrying the PW upstream label will be encapsulated according to the methods described in [RFC5332].
P2MP PW需要一个MPLS LSP来承载PW流量，携带PW上游标签的MPLS数据包将按照[RFC5332]中描述的方法进行封装。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
AGI: Attachment Group Identifier
AGI:附件组标识符
CE: Customer Edge
行政长官：顾客优势
FEC: Forwarding Equivalence Class
转发等价类
L-PE: Leaf PE (egress PE)
L-PE：叶片PE（出口PE）
LDP: Label Distribution Protocol
标签分发协议
LSP: Label Switched Path
标签交换路径
mLDP: Multipoint Label Distribution Protocol (for P2MP/MP2MP LSP)
mLDP：多点标签分发协议（用于P2MP/MP2MP LSP）
MS-PW: Multi-Segment Pseudowire
MS-PW：多段伪导线
P2MP: Point-to-Multipoint
P2MP：点对多点
P2P: Point-to-Point
P2P：点对点
PE: Provider Edge
PE：提供程序边缘
PSN: Packet Switched Network
分组交换网络
PW: Pseudowire
伪线
R-PE: Root PE (ingress PE, PE initiating P2MP PW setup)
R-PE：根PE（入口PE，PE启动P2MP PW设置）
S-PE: Switching Provider Edge (of MS-PW)
S-PE：交换提供程序边缘（MS-PW的）
SS-PW: Single-Segment Pseudowire
SS-PW：单段伪导线
TE: Traffic Engineering
交通工程
In order to advertise labels as well as exchange PW-related LDP messages, PEs must establish LDP sessions among themselves. A PE discovers other PEs that are to be connected via P2MP PWs either via manual configuration or autodiscovery [RFC6074].
为了宣传标签以及交换与PW相关的LDP消息，PEs必须在它们之间建立LDP会话。PE通过手动配置或自动发现发现将通过P2MP PWs连接的其他PE[RFC6074]。
An R-PE and each L-PE MUST be configured with the same FEC as defined in Section 3.2.
R-PE和L-PE必须配置第3.2节中定义的相同FEC。
P2MP PW requires that there be an active P2MP PSN LSP set up between an R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP is different depending on the signaling protocol used (RSVP-TE or mLDP).
P2MP PW要求在R-PE和L-PE之间设置有效的P2MP PSN LSP。注意，根据所使用的信令协议（RSVP-TE或mLDP），设置P2MP PSN LSP的程序不同。
In the case of mLDP, a Leaf PE can decide to join the P2MP LSP at any time. In the case of RSVP-TE, the P2MP LSP is set up by the R-PE, generally at the initial service provisioning time. It should be noted that local policy can override any decision to join, add, or prune existing or new L-PEs from the tree. In any case, the PW setup can ignore these differences and simply assume that the P2MP PSN LSP is available when needed.
在mLDP的情况下，叶PE可以随时决定加入P2MP LSP。在RSVP-TE的情况下，P2MP LSP通常在初始服务提供时由R-PE设置。应该注意的是，本地策略可以覆盖从树中加入、添加或删除现有或新L-PE的任何决定。在任何情况下，PW设置都可以忽略这些差异，并简单地假设P2MP PSN LSP在需要时可用。
P2MP PW signaling is initiated by the R-PE, which sends a separate P2MP PW LDP Label Mapping Message to each of the L-PE(s) belonging to that P2MP PW. This Label Mapping Message will contain the following:
P2MP PW信令由R-PE发起，R-PE向属于该P2MP PW的每个L-PE发送单独的P2MP PW LDP标签映射消息。此标签映射消息将包含以下内容：
1. A FEC TLV containing a P2MP PW Upstream FEC Element that includes a Transport LSP sub-TLV.
1. 包含P2MP PW上游FEC元件的FEC TLV，该FEC TLV包括传输LSP子TLV。
2. An Interface Parameters TLV, as described in [RFC8077].
2. 接口参数TLV，如[RFC8077]所述。
3. A PW Group ID TLV, as described in [RFC8077].
3. PW组ID TLV，如[RFC8077]中所述。
4. A label TLV for the upstream-assigned label used by an R-PE for the traffic going from the R-PE to L-PE(s).
4. R-PE用于从R-PE到L-PE的流量的上游分配标签的标签TLV。
The R-PE imposes the upstream-assigned PW label on the outbound packets sent over the P2MP PW; using this label, an L-PE identifies the inbound packets arriving over the P2MP PW.
R-PE在通过P2MP PW发送的出站分组上施加上游分配的PW标签；使用此标签，L-PE识别通过P2MP PW到达的入站数据包。
Additionally, the R-PE MAY send Label Mapping Messages to one or more L-PEs to signal a unidirectional P2P PW(s). The L-PE(s) can use such a PW(s) to send traffic to the R-PE. This optional Label Mapping Message will contain the following:
另外，R-PE可以向一个或多个L-PE发送标签映射消息，以向单向P2P PW发送信号。L-PE可以使用这样的PW向R-PE发送通信量。此可选标签映射消息将包含以下内容：
1. A P2P PW Downstream FEC Element
1. P2P-PW下游FEC元素
2. A label TLV for the downstream-assigned label used by the corresponding L-PE to send traffic to the R-PE
2. 对应L-PE用于向R-PE发送流量的下游分配标签的标签TLV
The LDP liberal label retention mode MUST be used; per requirements specified in [RFC5036], the Label Request message MUST also be supported.
必须使用LDP自由标签保留模式；根据[RFC5036]中规定的要求，还必须支持标签请求消息。
The upstream-assigned label is allocated according to the rules in [RFC5331].
根据[RFC5331]中的规则分配上游分配的标签。
When an L-PE receives a PW Label Mapping Message, it MUST verify the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place and its type is LDP P2MP LSP, the L-PE MUST attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW and MUST notify the user. In this case, a PW status message with status code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST also be sent to the R-PE.
当L-PE收到PW标签映射消息时，必须验证相关的P2MP PSN LSP是否到位。如果相关联的P2MP PSN LSP未就位且其类型为LDP P2MP LSP，则L-PE必须尝试加入与P2MP PW相关联的P2MP LSP。如果相关的P2MP PSN LSP不到位，且其类型为RSVP-TE P2MP LSP，则L-PE应等待P2MP传输LSP发出信号。如果L-PE未能加入P2MP PSN LSP，则该L-PE不得启用PW，且必须通知用户。在这种情况下，还必须向R-PE发送状态代码为0x00000008（面向PW（入口）接收故障的本地PSN）的PW状态消息。
If an R-PE signals a PW with a PW Type, Control Word (CW) mode, or interface parameters that a particular L-PE cannot accept, then the L-PE MUST NOT enable the PW and should notify the user. In this case, a PW status message with status code of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent to the R-PE.
如果R-PE用特定L-PE无法接受的PW类型、控制字（CW）模式或接口参数向PW发送信号，则L-PE不得启用PW，并应通知用户。在这种情况下，还必须向R-PE发送状态代码为0x00000001（伪线不转发）的PW状态消息。
Note that this procedure does not apply if the L-PE was not provisioned with this particular P2MP PW. In this case, according to the LDP liberal label retention rules, no action is taken.
请注意，如果L-PE未配备此特定P2MP PW，则此程序不适用。在这种情况下，根据LDP自由标签保留规则，不采取任何行动。
[RFC8077] specifies two types of LDP FEC elements used to signal P2P PWs: "PWid FEC Element" and "Generalized PWid FEC Element". This document uses two FEC elements: "P2MP PW Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC elements are associated with a mandatory upstream-assigned label and an optional downstream-assigned label, respectively.
[RFC8077]指定了用于向P2P PWs发送信号的两种类型的LDP FEC元素：“PWid FEC元素”和“广义PWid FEC元素”。本文档使用两个FEC元素：“P2MP PW上游FEC元素”和“P2P PW下游FEC元素”。这些FEC元素分别与强制性上游分配标签和可选下游分配标签相关联。
The FEC type for the P2MP PW Upstream FEC Element is encoded as follows:
P2MP PW上游FEC元素的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 PW Up=0x82|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PMSI Tunnel Typ|PMSI TT Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ +
~ Transport LSP ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 PW Up=0x82|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PMSI Tunnel Typ|PMSI TT Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ +
~ Transport LSP ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: P2MP PW Upstream FEC Element
图2:P2MP PW上游FEC元件
* P2MP PW Up:
* P2MP PW Up：
8-bit representation for the P2MP PW Upstream FEC type.
P2MP PW上游FEC类型的8位表示。
* C bit:
* C位：
A value of 1 or 0 indicating whether a control word is present or absent for the P2MP PW.
1或0的值，指示P2MP PW是否存在控制字。
* PW Type:
* PW类型：
15-bit representation of PW Type as specified in [RFC8077].
[RFC8077]中规定的PW类型的15位表示。
* PW Info Length:
* PW信息长度：
Sum of the AGI Length, SAII Length, PMSI Tunnel Type Length, and Optional Parameters fields in octets. If this value is 0, then it references all PWs using the specified group ID. In this case, there are neither other FEC element fields (AGI Type, SAII Value, etc.) present, nor any interface parameters TLVs. Alternatively, typed wildcard FEC described in Section 2.3, can be used to achieve the same or to have better filtering.
AGI长度、SAII长度、PMSI隧道类型长度和可选参数字段的总和（以八位字节为单位）。如果该值为0，则它使用指定的组ID引用所有PW。在这种情况下，不存在其他FEC元素字段（AGI类型、SAII值等），也不存在任何接口参数TLV。或者，第2.3节中描述的类型化通配符FEC可用于实现相同或更好的过滤。
* AGI:
* AGI：
An Attachment Group Identifier TLV can be used to uniquely identify a VPN or Virtual Private LAN Service (VPLS) instance associated with the P2MP PW. This has the same format as the Generalized PWid FEC Element [RFC8077].
附件组标识符TLV可用于唯一标识与P2MP PW关联的VPN或虚拟专用LAN服务（VPLS）实例。这与通用PWid FEC元素[RFC8077]的格式相同。
* SAII Value:
* SAII值：
A Source Attachment Individual Identifier is used to identify the root of the P2MP PW. The root is represented using AII Type 2 format specified in [RFC5003]. Note that the SAII can be omitted by simply setting the length and type to zero.
源附件单个标识符用于标识P2MP PW的根。根使用[RFC5003]中指定的AII类型2格式表示。请注意，只需将长度和类型设置为零，即可省略SAII。
The P2MP PW is identified by the Source Attachment Identifier (SAI). If the AGI is non-null, the SAI is the combination of the SAII and the AGI, if the AGI is null, the SAI is the SAII.
P2MP PW由源附件标识符（SAI）标识。如果AGI为非空，则SAI为SAII和AGI的组合；如果AGI为空，则SAI为SAII。
* PMSI Tunnel Info:
* PMSI隧道信息：
The PMSI Tunnel Info is the combination of the PMSI Tunnel Type, PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), and Transport LSP ID fields.
PMSI隧道信息是PMSI隧道类型、PMSI隧道类型长度（图中显示为PMSI TT长度）和传输LSP ID字段的组合。
A P2MP PW MUST be associated with a transport LSP, which can be established using RSVP-TE or mLDP.
P2MP PW必须与可使用RSVP-TE或mLDP建立的传输LSP相关联。
* PMSI Tunnel Type:
* PMSI隧道类型：
The PMSI Tunnel Type is defined in [RFC6514].
PMSI隧道类型在[RFC6514]中定义。
When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element as defined in [RFC6388]. The new mLDP Opaque Value Element type for the L2VPN-MCAST application TLV (as specified in the IANA Considerations section (Section 7)) MUST be used.
当类型设置为mLDP P2MP LSP时，隧道标识符是[RFC6388]中定义的P2MP FEC元素。必须使用L2VPN-MCAST应用程序TLV的新mLDP不透明值元素类型（如IANA注意事项部分（第7节）中的规定）。
* Transport LSP ID:
* 传输LSP ID:
This is the Tunnel Identifier that is defined in [RFC6514].
这是[RFC6514]中定义的隧道标识符。
An R-PE sends a Label Mapping Message as soon as the transport LSP ID associated with the P2MP PW is known (e.g., via configuration) regardless of the operational state of that transport LSP.
只要与P2MP PW相关联的传输LSP ID已知（例如，通过配置），R-PE就发送标签映射消息，而不管该传输LSP的操作状态如何。
Similarly, an R-PE does not withdraw the labels when the corresponding transport LSP goes down. Furthermore, an L-PE retains the P2MP PW labels regardless of the operational status of the transport LSP.
类似地，当相应的传输LSP下降时，R-PE不收回标签。此外，无论运输LSP的运行状态如何，L-PE都会保留P2MP PW标签。
Note that a given transport LSP can be associated with more than one P2MP PW; in which case, P2MP PWs will be sharing the same R-PE and L-PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets.
注意，给定的传输LSP可以与多个P2MP PW相关联；在这种情况下，P2MP PW将共享相同的R-PE和L-PE。一个R-PE也可能有许多具有不相交L-PE集的P2MP PW。
In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping Message, it can initiate the process of joining the P2MP LSP tree associated with the P2MP PW.
在LDP P2MP LSP的情况下，当L-PE接收到标签映射消息时，它可以启动加入与P2MP PW相关联的P2MP LSP树的过程。
In the case of RSVP-TE P2MP LSP, only the R-PE initiates the signaling of P2MP LSP.
在RSVP-TE P2MP LSP的情况下，只有R-PE发起P2MP LSP的信令。
* Optional Parameters:
* 可选参数：
The Optional Parameter field can contain some TLVs that are not part of the FEC, but are necessary for the operation of the PW. This proposed mechanism uses two such TLVs: the Interface Parameters TLV and the PW Group ID TLV.
可选参数字段可以包含一些TLV，这些TLV不是FEC的一部分，但却是PW运行所必需的。这个提议的机制使用了两个这样的TLV：接口参数TLV和PW组ID TLV。
The Interface Parameters TLV and PW Group ID TLV specified in [RFC8077] can also be used in conjunction with P2MP PW FEC in a label message. For the PW Group ID TLV, the sender and receiver of these TLVs should follow the same rules and procedures specified in [RFC8077]. For the Interface Parameters TLV, the procedure differs from the one specified in [RFC8077] due to specifics of P2MP connectivity. When the interface parameters are signaled by an R-PE, each L-PE must check if its configured value(s) is less than or equal to the threshold value provided by the R-PE (e.g., MTU size (Ethernet), max number of concatenated ATM cells, etc.). For other interface parameters, like CEP/TDM Payload Bytes, the value MUST exactly match the values signaled by the R-PE.
[RFC8077]中指定的接口参数TLV和PW组ID TLV也可以与标签消息中的P2MP PW FEC一起使用。对于PW组ID TLV，这些TLV的发送方和接收方应遵循[RFC8077]中规定的相同规则和程序。对于接口参数TLV，由于P2MP连接的特殊性，该程序与[RFC8077]中规定的程序不同。当接口参数由R-PE发出信号时，每个L-PE必须检查其配置值是否小于或等于R-PE提供的阈值（例如，MTU大小（以太网）、串联ATM信元的最大数量等）。对于其他接口参数，如CEP/TDM有效负载字节，该值必须与R-PE发出的信号值完全匹配。
A multicast traffic stream associated with a P2MP PW can be selective or inclusive. To support the former, this document defines a new optional Selective Tree Interface Parameter sub-TLV, as described in the IANA Considerations section (Section 7) and according to the format described in [RFC8077]. The value of the sub-TLV contains the source and the group for a given multicast tree, as shown in Figure 3. Also, if a P2MP PW is associated with multiple selective trees, the corresponding Label Mapping Message will carry more than one instance of this sub-TLV. Furthermore, in the absence of this sub-TLV, the P2MP PW is associated with all multicast traffic streams originating from the root.
与P2MP PW相关联的多播业务流可以是选择性的或包含性的。为了支持前者，本文档定义了一个新的可选选择性树接口参数sub-TLV，如IANA注意事项部分（第7节）所述，并符合[RFC8077]中所述的格式。sub TLV的值包含给定多播树的源和组，如图3所示。此外，如果P2MP PW与多个选择性树关联，则相应的标签映射消息将携带该子TLV的多个实例。此外，在缺少该子TLV的情况下，P2MP PW与源于根的所有多播业务流相关联。
+-----------------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------------+
| Length (1 Octet) |
+-----------------------------------------+
| Multicast Source Length (1 Octet) |
+-----------------------------------------+
| Multicast Source (variable length) |
+-----------------------------------------+
| Multicast Group Length (1 Octet) |
+-----------------------------------------+
| Multicast Group (variable length) |
+-----------------------------------------+
+-----------------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------------+
| Length (1 Octet) |
+-----------------------------------------+
| Multicast Source Length (1 Octet) |
+-----------------------------------------+
| Multicast Source (variable length) |
+-----------------------------------------+
| Multicast Group Length (1 Octet) |
+-----------------------------------------+
| Multicast Group (variable length) |
+-----------------------------------------+
Figure 3: Selective Tree Interface Parameter Sub-TLV Value
图3：选择性树接口参数子TLV值
Note that since the LDP Label Mapping Message is only sent by the R-PE to all the L-PEs, it is not possible to negotiate any interface parameters.
注意，由于LDP标签映射消息仅由R-PE发送到所有L-PE，因此不可能协商任何接口参数。
The optional P2P PW Downstream FEC Element is encoded as follows:
可选的P2P PW下游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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2P PWDown=0x84|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2P PWDown=0x84|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: P2P PW Downstream FEC Element
图4:P2P PW下游FEC元件
The definition of the fields in the P2P PW Downstream FEC Element is the same as those of P2MP PW Upstream FEC Element, shown in Figure 2.
P2P PW下游FEC元素中的字段定义与P2MP PW上游FEC元素中的字段定义相同，如图2所示。
[RFC5918] defines the general notion of a Typed Wildcard FEC Element; it requires FEC designers to specify a Typed Wildcard FEC Element for newly defined FEC element types. This document uses two FEC elements: "P2MP PW Upstream" and "P2P PW Downstream". Hence, definition of their Typed Wildcard format is required.
[RFC5918]定义了类型化通配符FEC元素的一般概念；它要求FEC设计器为新定义的FEC元素类型指定类型化通配符FEC元素。本文档使用两个FEC元素：“P2MP PW上游”和“P2P PW下游”。因此，需要定义其类型化通配符格式。
[RFC6667] defines the Typed Wildcard FEC Element format for other PW FEC Element types (PWid and Generalized PWid FEC Element) in Section 3 as follows:
[RFC6667]在第3节中为其他PW FEC元素类型（PWid和广义PWid FEC元素）定义了类型化通配符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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | PMSI Tun Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | PMSI Tun Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Typed Wildcard Format for P2MP PW FEC Elements
图5:P2MP PW FEC元素的类型化通配符格式
[RFC6667] specifies that the Type field can be either the "PWid" (0x80) or "Generalized PWid" (0x81) FEC Element type. This document reuses the existing Typed Wildcard format specified in [RFC6667] and illustrated in Figure 5 and extends the definition of the Type field to also include the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element types. This document adds an additional field called the "PMSI Tunnel Type". This document reserves PMSI Tunnel Type 0xFF to mean "wildcard transport tunnel type". The PMSI Tunnel Type field only applies to the Typed Wildcard P2MP PW Upstream FEC Element and MUST be set to "wildcard" for "P2P PW Downstream FEC Element" typed wildcard.
[RFC6667]指定类型字段可以是“PWid”（0x80）或“广义PWid”（0x81）FEC元素类型。本文档重用了[RFC6667]中指定并在图5中说明的现有类型通配符格式，并扩展了类型字段的定义，以包括P2MP PW上游FEC元素和P2P PW下游FEC元素类型。本文档添加了一个名为“PMSI隧道类型”的附加字段。本文件将PMSI隧道类型0xFF保留为“通配符传输隧道类型”。PMSI隧道类型字段仅适用于类型化通配符P2MP PW上游FEC元素，对于“P2P PW下游FEC元素”类型的通配符，必须设置为“通配符”。
The PW Group ID TLV as defined in [RFC8077] contains a group ID capable of indicating an arbitrary group membership of a P2MP PW. This group ID can be used in LDP "wildcard" status and withdraw label messages, as described in [RFC8077].
[RFC8077]中定义的PW组ID TLV包含能够指示P2MP PW的任意组成员身份的组ID。此组ID可用于LDP“通配符”状态和撤销标签消息，如[RFC8077]所述。
As in the case of P2P PW signaling, P2MP PW labels are carried within the Generic Label TLV contained in the LDP Label Mapping Message. A Generic Label TLV is formatted and processed as per the rules and procedures specified in [RFC8077]. For a given P2MP PW, a single upstream-assigned label is allocated by the R-PE and is advertised to all L-PEs using the Generic Label TLV in Label Mapping Messages containing the P2MP PW Upstream FEC Element.
与P2P PW信令的情况一样，P2MP PW标签携带在LDP标签映射消息中包含的通用标签TLV内。通用标签TLV按照[RFC8077]中规定的规则和程序进行格式化和处理。对于给定的P2MP PW，R-PE分配单个上游分配的标签，并使用包含P2MP PW上游FEC元素的标签映射消息中的通用标签TLV向所有L-PE播发。
The R-PE can also allocate a unique label for each L-PE from which it intends to receive P2P traffic. Such a label is advertised to the L-PE using the Generic Label TLV and P2P PW Downstream FEC Element in Label Mapping Messages.
R-PE还可以为其打算从中接收P2P流量的每个L-PE分配唯一的标签。使用标签映射消息中的通用标签TLV和P2P PW下游FEC元素向L-PE通告这样的标签。
The capability of supporting P2MP PWs MUST be advertised to all LDP peers. This is achieved by using the methods in [RFC5561] to advertise the LDP P2MP PW Capability TLV. If an LDP peer supports the dynamic capability advertisement, this can be done by sending a new Capability message with the S bit set for the P2MP PW Capability TLV. If the peer does not support dynamic capability advertisement, then the P2MP PW Capability TLV MUST be included in the LDP Initialization message during session establishment. A Label Switched Router (LSR) having P2MP PW capability MUST recognize both the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in LDP label messages.
必须向所有LDP对等方公布支持P2MP PWs的能力。这是通过使用[RFC5561]中的方法宣传LDP P2MP PW能力TLV实现的。如果LDP对等方支持动态能力通告，则可以通过发送新的能力消息来完成，该消息的S位设置为P2MP PW能力TLV。如果对等方不支持动态能力播发，则在会话建立期间，必须在LDP初始化消息中包括P2MP PW能力TLV。具有P2MP PW能力的标签交换路由器（LSR）必须识别LDP标签消息中的P2MP PW上游FEC元素和P2P PW下游FEC元素。
In line with requirements listed in [RFC5561], the following TLV is defined to indicate the P2MP PW capability:
根据[RFC5561]中列出的要求，定义以下TLV以指示P2MP PW能力：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| P2MP PW Capability TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| P2MP PW Capability TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: LDP P2MP PW Capability TLV
图6:LDP P2MP PW能力TLV
* U bit:
* U位：
The Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood).
未知位[RFC5036]应为1（如果不理解，则忽略）。
* F bit:
* F位：
The Forward unknown bit [RFC5036] SHOULD be 0 (don't forward if not understood).
前向未知位[RFC5036]应为0（如果不理解，请勿前向）。
* P2MP PW Capability TLV Code Point:
* P2MP PW能力TLV代码点：
The TLV type, which identifies a specific capability. Note that the P2MP PW Capability Code Point appears in the IANA Considerations section (Section 7).
TLV类型，用于标识特定能力。请注意，P2MP PW能力代码点出现在IANA注意事项部分（第7节）。
* S bit:
* S位：
The State Bit indicates whether the sender is advertising or withdrawing the P2MP PW capability. The State bit is used as follows:
状态位表示发送方是在宣传还是在撤回P2MP PW功能。状态位的使用方式如下：
1 - The TLV is advertising the capability specified by the P2MP PW Capability TLV Code Point.
1-TLV正在公布P2MP PW能力TLV代码点指定的能力。
0 - The TLV is withdrawing the capability specified by the P2MP PW Capability TLV Code Point.
0-TLV正在撤回P2MP PW能力TLV代码点指定的能力。
* Length:
* 长度：
MUST be set to 2 (octet).
必须设置为2（八位字节）。
In order to support the proposed mechanism, an LSR MUST be capable of handling PW status. As such, the PW status negotiation procedures described in [RFC8077] are not applicable to P2MP PW. An LSR MUST NOT claim to be P2MP PW capable by sending an LDP P2MP PW Capability TLV if it is not also capable of handling PW status.
为了支持提议的机制，LSR必须能够处理PW状态。因此，[RFC8077]中描述的PW状态协商程序不适用于P2MP PW。如果LSR不能处理PW状态，则不得通过发送LDP P2MP PW能力TLV声称其具有P2MP PW能力。
Once an L-PE successfully processes a Label Mapping Message for a P2MP PW, it MUST send appropriate PW status according to the procedure specified [RFC8077] to report the PW status. If no PW status notification is required, then no PW status notification is sent (for example, if the P2MP PW is established and operational with a status code of 0x00000000 (Success), a PW status message is not necessary). A PW status message sent from an L-PE to an R-PE MUST contain the P2P PW Downstream FEC Element to identify the PW.
一旦L-PE成功处理P2MP PW的标签映射消息，它必须根据指定的程序[RFC8077]发送适当的PW状态以报告PW状态。如果不需要PW状态通知，则不发送PW状态通知（例如，如果P2MP PW已建立并可运行，状态代码为0x00000000（成功），则不需要PW状态消息）。从L-PE发送到R-PE的PW状态消息必须包含P2P PW下游FEC元素，以识别PW。
An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP PW state. Such a PW status message contains a P2MP PW Upstream FEC Element to identify the PW.
R-PE还向L-PE发送PW状态，以反映其对P2MP PW状态的看法。此类PW状态消息包含P2MP PW上游FEC元素，用于识别PW。
Connectivity status of the underlying P2MP LSP that the P2MP PW is associated with can be verified using LSP ping and traceroute procedures described in [RFC6425].
可使用[RFC6425]中所述的LSP ping和traceroute程序验证与P2MP PW相关的基础P2MP LSP的连接状态。
In general, the security measures described in [RFC8077] are adequate for this protocol. However, the use of MD5 as the method of securing an LDP control plane is no longer considered adequately secure. Implementations should be written in such a way that they can migrate to a more secure cryptographic hash function when the next authentication method to be used in the LDP might not be a simple hash-based authentication algorithm.
一般而言，[RFC8077]中描述的安全措施足以满足本协议的要求。然而，将MD5用作保护LDP控制平面的方法不再被认为是足够安全的。应以这样的方式编写实现，即当LDP中要使用的下一个身份验证方法可能不是简单的基于哈希的身份验证算法时，它们可以迁移到更安全的加密哈希函数。
This document uses two FEC element types, 0x82 and 0x84, in the "Forwarding Equivalence Class (FEC) Type Name Space" registry for the Label Distribution Protocol (LDP) [RFC5036]. IANA has added this document as a reference for the following entries:
本文档在标签分发协议（LDP）[RFC5036]的“转发等价类（FEC）类型名称空间”注册表中使用两种FEC元素类型0x82和0x84。IANA已添加本文件作为以下条目的参考：
Value Hex Name Reference
------ ----- ----------------------------- --------------------
130 0x82 P2MP PW Upstream FEC Element [RFC8338] [RFC7358]
132 0x84 P2P PW Downstream FEC Element [RFC8338] [RFC7358]
Value Hex Name Reference
------ ----- ----------------------------- --------------------
130 0x82 P2MP PW Upstream FEC Element [RFC8338] [RFC7358]
132 0x84 P2P PW Downstream FEC Element [RFC8338] [RFC7358]
This document defines a new LDP TLV type in the "TLV Type Name Space" registry [RFC5036]. IANA has assigned the following value:
本文档在“TLV类型名称空间”注册表[RFC5036]中定义了一个新的LDP TLV类型。IANA已指定以下值：
TLV Type Description
-------- ----------------------
0x0703 P2MP PW Capability TLV
TLV Type Description
-------- ----------------------
0x0703 P2MP PW Capability TLV
IANA has assigned a new mLDP Opaque Value Element Type in the "LDP MP Opaque Value Element basic type" registry [RFC6388] as follows:
IANA在“LDP MP不透明值元素基本类型”注册表[RFC6388]中分配了一个新的mLDP不透明值元素类型，如下所示：
TLV Type Description
------- ---------------------------
13 L2VPN-MCAST application TLV
TLV Type Description
------- ---------------------------
13 L2VPN-MCAST application TLV
Length: 4
长度：4
Value: A 32-bit integer, unique in the context of the root, as identified by the root's address.
值：一个32位整数，在根的上下文中是唯一的，由根的地址标识。
IANA has assigned a sub-TLV from the "Pseudowire Interface Parameters Sub-TLV type Registry" [RFC4446] as follows:
IANA已从“伪线接口参数子TLV类型注册表”[RFC4446]分配子TLV，如下所示：
TLV Type Description
-------- ----------------------------------
0x1B Selective Tree Interface Parameter
TLV Type Description
-------- ----------------------------------
0x1B Selective Tree Interface Parameter
IANA has modified an entry in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry [RFC7385]. Value 0xFF, which was previously marked as "Reserved", has been updated as follows:
IANA已在“边界网关协议（BGP）参数”注册表[RFC7385]中修改了“P-多播服务接口隧道（PMSI隧道）隧道类型”注册表中的一个条目。先前标记为“保留”的值0xFF已更新如下：
Value Meaning Reference
----- ------------------------------ ---------
0xFF wildcard transport tunnel type [RFC8338]
Value Meaning Reference
----- ------------------------------ ---------
0xFF wildcard transport tunnel type [RFC8338]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，DOI 10.17487/RFC4446，2006年4月<https://www.rfc-editor.org/info/rfc4446>.
[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, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，DOI 10.17487/RFC4875，2007年5月<https://www.rfc-editor.org/info/rfc4875>.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, DOI 10.17487/RFC5003, September 2007, <https://www.rfc-editor.org/info/rfc5003>.
[RFC5003]Metz，C.，Martini，L.，Balus，F.，和J.Sugimoto，“聚合的附件个人标识符（AII）类型”，RFC 5003，DOI 10.17487/RFC5003，2007年9月<https://www.rfc-editor.org/info/rfc5003>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<https://www.rfc-editor.org/info/rfc5036>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<https://www.rfc-editor.org/info/rfc5331>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，DOI 10.17487/RFC5332，2008年8月<https://www.rfc-editor.org/info/rfc5332>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 5561，DOI 10.17487/RFC55611909年7月<https://www.rfc-editor.org/info/rfc5561>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, <https://www.rfc-editor.org/info/rfc5918>.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 5918，DOI 10.17487/RFC5918，2010年8月<https://www.rfc-editor.org/info/rfc5918>.
[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, DOI 10.17487/RFC6388, November 2011, <https://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<https://www.rfc-editor.org/info/rfc6388>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<https://www.rfc-editor.org/info/rfc6514>.
[RFC6667] Raza, K., Boutros, S., and C. Pignataro, "LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements", RFC 6667, DOI 10.17487/RFC6667, July 2012, <https://www.rfc-editor.org/info/rfc6667>.
[RFC6667]Raza，K.，Boutros，S.，和C.Pignataro，“PWid和广义PWid FEC元素的LDP‘类型通配符’转发等价类（FEC）”，RFC 6667，DOI 10.17487/RFC6667，2012年7月<https://www.rfc-editor.org/info/rfc6667>.
[RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <https://www.rfc-editor.org/info/rfc7385>.
[RFC7385]Andersson，L.和G.Swallow，“P-多播服务接口（PMSI）隧道类型代码点的IANA注册”，RFC 7385，DOI 10.17487/RFC7385，2014年10月<https://www.rfc-editor.org/info/rfc7385>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077]Martini，L.，Ed.和G.Heron，Ed.，“使用标签分发协议（LDP）的伪线设置和维护”，STD 84，RFC 8077，DOI 10.17487/RFC8077，2017年2月<https://www.rfc-editor.org/info/rfc8077>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<https://www.rfc-editor.org/info/rfc3985>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，DOI 10.17487/RFC6074，2011年1月<https://www.rfc-editor.org/info/rfc6074>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>.
[RFC6425]Saxena，S.，Ed.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 6425，DOI 10.17487/RFC6425，2011年11月<https://www.rfc-editor.org/info/rfc6425>.
[RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", RFC 7338, DOI 10.17487/RFC7338, September 2014, <https://www.rfc-editor.org/info/rfc7338>.
[RFC7338]Jounay，F.，Ed.，Kamite，Y.，Ed.，Heron，G.，和M.Bocci，“MPLS分组交换网络上点对多点伪线的要求和框架”，RFC 7338，DOI 10.17487/RFC7338，2014年9月<https://www.rfc-editor.org/info/rfc7338>.
[RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October 2014, <https://www.rfc-editor.org/info/rfc7358>.
[RFC7358]Raza，K.，Boutros，S.，Martini，L.，和N.Leymann，“LDP转发等价类（FEC）的标签广告规程”，RFC 7358，DOI 10.17487/RFC7358，2014年10月<https://www.rfc-editor.org/info/rfc7358>.
Acknowledgments
致谢
The authors would like to thank Andre Pelletier and Parag Jain for their valuable suggestions.
作者要感谢Andre Pelletier和Parag Jain提出的宝贵建议。
Contributors
贡献者
The following people contributed substantially to the content of this document and should be considered coauthors:
以下人员对本文件的内容做出了重大贡献，应被视为合著者：
Luca Martini Cisco Systems, Inc.
卢卡·马蒂尼思科系统公司。
Email: lmartini@cisco.com
Email: lmartini@cisco.com
Maciek Konstantynowicz Cisco Systems, Inc.
Maciek Konstantynowicz思科系统公司。
Email: maciek@cisco.com
Email: maciek@cisco.com
Gianni Del Vecchio Swisscom
吉安尼·德尔维奇奥瑞士酒店
Email: Gianni.DelVecchio@swisscom.com
Email: Gianni.DelVecchio@swisscom.com
Thomas D. Nadeau Brocade
托马斯·纳多·博科
Email: tnadeau@lucidvision.com
Email: tnadeau@lucidvision.com
Frederic Jounay Orange CH
弗雷德里克·朱内
Email: Frederic.Jounay@salt.ch
Email: Frederic.Jounay@salt.ch
Philippe Niger Orange CH
菲利普尼日尔橙
Email: philippe.niger@orange.com
Email: philippe.niger@orange.com
Yuji Kamite NTT Communications Corporation
Yuji Kamite NTT通信公司
Email: y.kamite@ntt.com
Email: y.kamite@ntt.com
Lizhong Jin
金立中
Email: lizho.jin@gmail.com
Email: lizho.jin@gmail.com
Martin Vigoureux Nokia
马丁·维古鲁诺基亚
Email: martin.vigoureux@nokia.com
Email: martin.vigoureux@nokia.com
Laurent Ciavaglia Nokia
诺基亚劳伦特·夏瓦格利亚酒店
Email: laurent.ciavaglia@nokia.com
Email: laurent.ciavaglia@nokia.com
Simon Delord Telstra
西蒙德洛德电信
Email: simon.delord@gmail.com
Email: simon.delord@gmail.com
Kamran Raza Cisco Systems
卡姆兰·拉扎思科系统公司
Email: skraza@cisco.com
Email: skraza@cisco.com
Authors' Addresses
作者地址
Sami Boutros (editor) VMware, Inc.
Sami Boutros（编辑）VMware公司。
Email: sboutros@vmware.com
Email: sboutros@vmware.com
Siva Sivabalan (editor) Cisco Systems, Inc.
Siva Sivabalan（编辑）思科系统公司。
Email: msiva@cisco.com
Email: msiva@cisco.com