Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5918 Cisco Systems
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
B. Thomas
August 2010
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5918 Cisco Systems
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
B. Thomas
August 2010
Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
标签分发协议（LDP）“类型通配符”前向等价类（FEC）
Abstract
摘要
The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility.
通配符前向等价类（FEC）元素的标签分发协议（LDP）规范有几个限制。本文档通过定义类型化通配符FEC元素和相关过程来解决这些限制。此外，它还定义了一个新的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/rfc5918.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5918.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 Language ..........................................4
3. The Typed Wildcard FEC Element ..................................4
4. Procedures for the Typed Wildcard FEC Element ...................5
5. Typed Wildcard FEC Capability ...................................6
6. Typed Wildcard FEC Element for Prefix FEC Element ...............7
7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...8
8. IANA Considerations .............................................8
9. Security Considerations .........................................8
10. Acknowledgments ................................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
1. Introduction ....................................................3
2. Specification Language ..........................................4
3. The Typed Wildcard FEC Element ..................................4
4. Procedures for the Typed Wildcard FEC Element ...................5
5. Typed Wildcard FEC Capability ...................................6
6. Typed Wildcard FEC Element for Prefix FEC Element ...............7
7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...8
8. IANA Considerations .............................................8
9. Security Considerations .........................................8
10. Acknowledgments ................................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
LDP [RFC5036] distributes labels for Forwarding Equivalence Classes (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP FEC TLV includes one or more FEC elements. A FEC element includes a FEC type and an optional type-dependent value.
LDP[RFC5036]为转发等价类（FEC）分发标签。LDP在LDP消息中使用FEC TLV来指定FEC。LDP FEC TLV包括一个或多个FEC元件。FEC元素包括FEC类型和可选的类型相关值。
RFC 5036 specifies two FEC types (Prefix and Wildcard), and other documents specify additional FEC types; e.g., see [RFC4447] and [MLDP].
RFC 5036指定了两种FEC类型（前缀和通配符），其他文档指定了其他FEC类型；e、 参见[RFC4447]和[MLDP]。
As specified by RFC 5036, the Wildcard FEC Element refers to all FECs relative to an optional constraint. The only constraint RFC 5036 specifies is one that limits the scope of the Wildcard FEC Element to "all FECs bound to a given label".
按照RFC 5036的规定，通配符FEC元素指的是相对于可选约束的所有FEC。RFC 5036指定的唯一约束是将通配符FEC元素的范围限制为“绑定到给定标签的所有FEC”。
The RFC 5036 specification of the Wildcard FEC Element has the following deficiencies that limit its utility:
通配符FEC元素的RFC 5036规范存在以下限制其实用性的缺陷：
1) The Wildcard FEC Element is untyped. There are situations where it would be useful to be able to refer to all FECs of a given type (as another constraint).
1) 通配符FEC元素是非类型化的。在某些情况下，能够引用给定类型的所有FEC（作为另一个约束）会很有用。
2) Use of the Wildcard FEC Element is limited to Label Withdraw and Label Release messages only. There are situations where it would be useful to have a Wildcard FEC Element, with type constraint, in Label Request messages.
2) 通配符FEC元素的使用仅限于标签撤消和标签释放消息。在某些情况下，在标签请求消息中使用带有类型约束的通配符FEC元素会很有用。
This document:
本文件：
- addresses the above limitations by defining a Typed Wildcard FEC Element and procedures for its use.
- 通过定义类型化通配符FEC元素及其使用过程来解决上述限制。
- specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling the Typed Wildcard FEC.
- 指定在会话建立时使用LDP能力机制[RFC5561]来通知对等方LDP说话人能够处理键入的通配符FEC。
- specifies use of the Typed Wildcard FEC Element in a Label Request message.
- 指定在标签请求消息中使用类型化通配符FEC元素。
- specifies the Typed Wildcard FEC Element for the Prefix FEC Element specified by RFC 5036.
- 为RFC 5036指定的前缀FEC元素指定类型化通配符FEC元素。
Note that this document does not change procedures specified for the LDP Wildcard FEC Element by RFC 5036.
注意，本文件不改变RFC 5036为LDP通配符FEC元素指定的程序。
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]中所述进行解释。
LDP - Label Distribution Protocol
标签分发协议
FEC - Forwarding Equivalence Class
转发等价类
TLV - Type Length Value
TLV-类型长度值
LSR - Label Switching Router
标签交换路由器
The Typed Wildcard FEC Element refers to all FECs of the specified type that meet the constraint. It specifies a 'FEC Element Type' and an optional constraint, which is intended to provide additional information.
类型化通配符FEC元素引用满足约束的指定类型的所有FEC。它指定了一个“FEC元素类型”和一个可选约束，用于提供附加信息。
The format of the Typed Wildcard FEC Element is:
类型化通配符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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed (0x05) | FEC Element | Len FEC Type | |
| Wildcard | Type | Info | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Additional FEC Type-specific Information ~
| (Optional) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed (0x05) | FEC Element | Len FEC Type | |
| Wildcard | Type | Info | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Additional FEC Type-specific Information ~
| (Optional) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Typed Wildcard FEC Element
图1：类型化通配符FEC元素
Where:
哪里：
Typed Wildcard: One-octet FEC Element Type (0x05).
类型化通配符：一个八位字节FEC元素类型（0x05）。
FEC Element Type: One-octet FEC Element Type that specifies the FEC Element Type to be wildcarded. Please see Section 3.4.1 of RFC 5036.
FEC元素类型：一个八位字节的FEC元素类型，指定要通配符的FEC元素类型。请参见RFC 5036第3.4.1节。
Any (future) document specifying a new FEC Element Type (not defined in RFC 5036) should prescribe whether typed wildcarding is needed for that FEC Element Type.
指定新FEC元素类型（RFC 5036中未定义）的任何（未来）文档应规定该FEC元素类型是否需要类型通配符。
Len FEC Type Info: One octet that specifies the length in octets of the FEC Type Specific information field. It MUST be set to 0 if there is no Additional FEC Type-specific Information.
Len FEC Type Info：一个八位字节，指定FEC Type特定信息字段的长度（以八位字节为单位）。如果没有其他FEC类型特定信息，则必须将其设置为0。
Additional FEC Type-specific Information (Optional): Additional information that is specific to the FEC Element Type and that is required to fully specify the Typed Wildcard. If this field is absent, then all FECs of the specified FEC Type would be matched.
附加FEC类型特定信息（可选）：特定于FEC元素类型且完全指定类型通配符所需的附加信息。如果此字段不存在，则将匹配指定FEC类型的所有FEC。
Any (future) document specifying Typed wildcarding for any FEC Element Type should also specify the length and format of Additional FEC Type Specific Information, if included.
为任何FEC元素类型指定类型通配符的任何（未来）文档还应指定附加FEC类型特定信息的长度和格式（如果包括）。
This document specifies one FEC Element Type instance (e.g., Prefix FEC) for the 'Typed Wildcard FEC Element' in Section 6.
本文档为第6节中的“类型化通配符FEC元素”指定了一个FEC元素类型实例（例如，前缀FEC）。
When a FEC TLV contains a Typed Wildcard FEC Element, the Typed Wildcard FEC Element MUST be the only FEC Element in the TLV. If an LDP speaker receives a FEC TLV containing a Typed Wildcard FEC Element and any other FEC elements, then the LDP speaker should ignore the other FEC elements and continue processing as if the message only contains the Typed Wildcard FEC Element.
当FEC TLV包含类型化通配符FEC元素时，类型化通配符FEC元素必须是TLV中唯一的FEC元素。如果LDP说话人接收到包含类型化通配符FEC元素和任何其他FEC元素的FEC TLV，则LDP说话人应忽略其他FEC元素并继续处理，就像消息仅包含类型化通配符FEC元素一样。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support its use in Label Request, Label Withdraw, and Label Release messages.
支持类型化通配符FEC元素的LDP实现必须支持其在标签请求、标签撤回和标签释放消息中的使用。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type defined in [RFC5036].
支持类型化通配符FEC元素的LDP实现必须为[RFC5036]中定义的每种FEC元素类型支持它。
Receipt of a Label Request message with a FEC TLV containing a Typed Wildcard FEC Element is interpreted as a request to send one or more Label Mappings for all FECs of the type specified by the FEC Element Type field in the Typed Wildcard FEC Element encoding.
通过包含类型化通配符FEC元素的FEC TLV接收标签请求消息被解释为请求为类型化通配符FEC元素编码中FEC元素类型字段指定类型的所有FEC发送一个或多个标签映射。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support the following constraints whenever a Typed Wildcard FEC appears in a Label Withdraw or Label Release message:
支持类型化通配符FEC元素的LDP实现必须在标签撤消或标签释放消息中出现类型化通配符FEC时支持以下约束：
1) If the message carries an optional Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified FEC type bound to the specified label.
1) 如果消息带有可选标签TLV，则类型化通配符FEC元素将引用绑定到指定标签的指定FEC类型的所有FEC。
2) If the message has no Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified FEC type.
2) 如果消息没有标签TLV，则类型化通配符FEC元素将引用指定FEC类型的所有FEC。
Backwards compatibility with a router not supporting the Typed Wildcard FEC element is ensured by the FEC procedures defined in RFC 5036. Quoting from RFC 5036:
RFC 5036中定义的FEC过程确保了与不支持类型通配符FEC元素的路由器的向后兼容性。引用RFC 5036：
If it [an LSR] encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
如果[LSR]遇到无法解码的FEC元素类型，则应停止解码FEC TLV，中止处理包含TLV的消息，并向其LDP对等方发送“未知FEC”通知消息，发出错误信号。
A router receiving a FEC TLV containing a Typed Wildcard FEC element for either a FEC Element Type that it doesn't support or for a FEC Element Type that doesn't support the use of wildcarding, MUST stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer to signal an error.
对于不支持的FEC元素类型或不支持使用通配符的FEC元素类型，接收包含类型通配符FEC元素的FEC TLV的路由器必须停止解码FEC TLV，中止处理包含TLV的消息，并发送“未知FEC”向其LDP对等方发送通知消息以发出错误信号。
A router receiving a FEC TLV containing a Typed Wildcard FEC element MAY also leverage mechanisms defined in [RFC5919] (say, if it had zero label binding for the requested FEC type, etc.).
接收包含类型化通配符FEC元素的FEC TLV的路由器也可以利用[RFC5919]中定义的机制（例如，如果它对请求的FEC类型具有零标签绑定，等等）。
As noted above, RFC 5036 FEC procedures provide for backward compatibility with an LSR not supporting the Typed Wildcard FEC Element. However, they don't provide means for an LSR that wishes to use the Typed Wildcard FEC Element to determine whether a peer supports it other than to send a message that uses the FEC Element and to wait and see how the peer responds.
如上所述，RFC 5036 FEC过程提供了与不支持类型通配符FEC元素的LSR的向后兼容性。但是，它们没有为希望使用类型化通配符FEC元素来确定对等方是否支持它的LSR提供方法，而只是发送使用FEC元素的消息并等待并查看对等方如何响应。
An LDP speaker that supports the Typed Wildcard FEC Element MUST inform its peers of the support by including a Typed Wildcard FEC Element Capability Parameter [RFC5561] in its Initialization messages only.
支持类型化通配符FEC元素的LDP说话人必须通过仅在其初始化消息中包含类型化通配符FEC元素能力参数[RFC5561]来通知其对等方支持。
The Capability Parameter for the Typed Wildcard FEC capability is a TLV with the following format:
类型化通配符FEC功能的功能参数是具有以下格式的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|Typed WCard FEC Cap(0x050B)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| 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|Typed WCard FEC Cap(0x050B)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 2: Typed Wildcard FEC Capability Format
图2：类型化通配符FEC能力格式
Where:
哪里：
U and F bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561].
U和F位：根据LDP功能[RFC5561]第3节，必须分别为1和0。
Typed WCard FEC Cap: 0x050B
键入的WCard FEC Cap:0x050B
Length: Two octets. It MUST be set to 0x0001.
长度：两个八位组。必须将其设置为0x0001。
S-bit: MUST be 1 (indicates that capability is being advertised).
S位：必须为1（表示正在公布功能）。
RFC 5036 defines the Prefix FEC Element, but it does not specify a Typed Wildcard for it. This section specifies the Typed Wildcard FEC Element for Prefix FEC Elements.
RFC 5036定义了前缀FEC元素，但没有为其指定类型通配符。本节指定前缀FEC元素的类型化通配符FEC元素。
The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC Wildcard" for short), based on Figure 1, is:
基于图1，前缀FEC类型的通配符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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = Prefix | Len = 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family |
+-+-+-+-+-+-+-+-+
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = Prefix | Len = 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family |
+-+-+-+-+-+-+-+-+
Figure 3: Format of Prefix FEC Element Using Typed Wildcard
图3：使用类型化通配符的前缀FEC元素的格式
Where:
哪里：
FEC Element Type: "Prefix" FEC Element (0x02, per RFC 5036).
FEC元素类型：“前缀”FEC元素（0x02，根据RFC 5036）。
Len FEC Type Info: Two octets. It MUST be set to 0x0002.
Len FEC类型信息：两个八位组。必须将其设置为0x0002。
Address Family: Two-octet quantity containing a value from the "ADDRESS FAMILY NUMBERS" registry on http://www.iana.org.
地址系列：两个八位字节的数量，包含上“地址系列号”注册表中的值http://www.iana.org.
The procedures described in Section 4 apply to the Prefix FEC Wildcard processing.
第4节中描述的过程适用于前缀FEC通配符处理。
There is no need to specify Typed Wildcard FEC Elements for the Host FEC Element specified by [RFC3036], nor for the Wildcard FEC Element specified by RFC 5036. The [RFC3036] Host FEC Element has been removed from RFC 5036, and the Wildcard FEC Element is untyped by definition.
不需要为[RFC3036]指定的主机FEC元素指定类型化通配符FEC元素，也不需要为RFC 5036指定的通配符FEC元素指定类型化通配符FEC元素。[RFC3036]主机FEC元素已从RFC 5036中删除，并且通配符FEC元素根据定义是非类型化的。
In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be either 0x01 or 0x03.
换句话说，“类型化通配符FEC元素”中的“FEC元素类型”字段不能为0x01或0x03。
This document introduces a new LDP FEC Element Type and a new LDP Capability, both of which have been assigned by IANA.
本文介绍了IANA分配的新LDP FEC元件类型和新LDP能力。
IANA has assigned a 'Typed Wildcard FEC Element' code point (0x05) from the LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The code point 0x05 is from the IETF Consensus range.
IANA已从LDP FEC类型名称空间分配了“类型化通配符FEC元素”代码点（0x05）。[RFC5036]将FEC类型名称空间划分为3个区域：IETF共识区域、先到先服务区域和专用区域。代码点0x05来自IETF共识范围。
IANA has assigned a 'Typed Wildcard FEC Capability' code point (0x050B) from the TLV Type name space. [RFC5036] partitions the TLV TYPE name space into 3 regions: IETF Consensus region, Vendor Private Use region, and Experimental Use region. The code point 0x050B is from the IETF Consensus range.
IANA已从TLV类型名称空间分配了“类型化通配符FEC功能”代码点（0x050B）。[RFC5036]将TLV类型名称空间划分为3个区域：IETF共识区域、供应商专用区域和实验使用区域。代码点0x050B来自IETF共识范围。
No security considerations beyond those that apply to the base LDP specification [RFC5036] and that are further described in [RFC5920] apply to use of the Typed Wildcard FEC Elements as described in this document.
除了适用于基本LDP规范[RFC5036]和[RFC5920]中进一步描述的安全注意事项外，没有其他安全注意事项适用于本文档中所述的类型化通配符FEC元素的使用。
One could deduce that the security exposure is reduced by this document, since an LDP speaker using the Typed Wildcard FEC Element could use a single message to request, withdraw, or release all the label mappings of a particular type (a particular Address Family Identifier (AFI), for example), whereas an LDP speaker using the Wildcard FEC Element, as defined in the base LDP specification [RFC5036], could use a single message to request, withdraw, or release all the label mappings of all types (all AFIs, for example).
可以推断，本文档减少了安全暴露，因为使用类型化通配符FEC元素的LDP说话人可以使用单个消息来请求、撤回或释放特定类型的所有标签映射（例如，特定地址族标识符（AFI）），而使用通配符FEC元素的LDP说话人，根据基本LDP规范[RFC5036]中的定义，可以使用单个消息来请求、撤销或释放所有类型（例如，所有AFI）的所有标签映射。
The authors would like to thank Yakov Rekhter for suggesting that the limitations of the Wildcard FEC be addressed. Also, thanks to Adrian Farrel, Kamran Raza, and Richard L. Barnes for extensive review of this document.
作者要感谢Yakov Rekhter建议解决通配符FEC的局限性。另外，感谢阿德里安·法雷尔、卡姆兰·拉扎和理查德·巴恩斯对本文件的广泛审查。
[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月。
[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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC5919] Asati, R., Mohapatra, P., Minei, I., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[RFC5919]Asati，R.，Mohapatra，P.，Minei，I.，和B.Thomas，“信号LDP标签广告完成”，RFC 5919，2010年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, July 2010.
[MLDP]Minei，I.，Ed.，Kompella，K.，Wijnands，I.，Ed.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2010年7月。
Authors' Addresses
作者地址
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. Research Triangle Park, NC 27709-4987 EMail: rajiva@cisco.com
Rajiv Asati Cisco Systems 7025-6北卡罗来纳州三角研究公园Kit Creek路27709-4987电子邮件：rajiva@cisco.com
Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net
Ina Minei Juniper Networks加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089电子邮件：ina@juniper.net
Bob Thomas EMail: bobthomas@alum.mit.edu
鲍勃·托马斯电子邮件：bobthomas@alum.mit.edu