Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7358 S. Boutros
Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
October 2014
Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7358 S. Boutros
Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
October 2014
Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)
LDP转发等价类（FEC）的标签广告规程
Abstract
摘要
The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.
给定转发等价类（FEC）的LDP说话人的标签广告行为由FEC类型控制，而不一定由LDP会话的协商标签广告模式控制。本文件更新了RFC 5036，以明确这一事实。它还通过为所有当前定义的LDP FEC类型指定标签广告模式来更新RFCs 3212、4447、5918、6388和7140。
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/rfc7358.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7358.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Label Advertisement Discipline ..................................3
2.1. Update to RFC 5036 .........................................3
2.2. Specification for LDP FECs .................................4
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction ....................................................2
2. Label Advertisement Discipline ..................................3
2.1. Update to RFC 5036 .........................................3
2.2. Specification for LDP FECs .................................4
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
The Label Distribution Protocol (LDP) [RFC5036] allows label advertisement mode negotiation at the time of session establishment. The LDP specification also dictates that only a single label advertisement mode be negotiated, agreed upon, and used for a given LDP session between two Label Switching Routers (LSRs).
标签分发协议（LDP）[RFC5036]允许在会话建立时进行标签广告模式协商。LDP规范还规定，在两个标签交换路由器（LSR）之间的给定LDP会话中，只能协商、商定和使用单标签广告模式。
The negotiated label advertisement mode defined in RFC 5036 and carried in the LDP Initialization message is only indicative. It indicates how the LDP speakers on a session will advertise labels for some Forwarding Equivalence Classes (FECs), but it is not a rule that restricts the speakers to behave in a specific way. Furthermore, for some FEC types the advertising behavior of the LDP speaker is governed by the FEC type and not by the negotiated behavior.
在RFC 5036中定义并在LDP初始化消息中携带的协商标签广告模式只是指示性的。它表示会话中的LDP演讲者将如何为某些转发等价类（FEC）发布标签，但这不是限制演讲者以特定方式行为的规则。此外，对于某些FEC类型，LDP说话人的广告行为由FEC类型而不是协商行为控制。
This document updates [RFC5036] to make that fact clear. It also updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to indicate, for each FEC type that has already been defined, whether
本文件更新了[RFC5036]以明确这一事实。它还更新了[RFC3212]、[RFC4447]、[RFC5918]、[RFC6388]和[RFC7140]，以指示对于已定义的每个FEC类型
the label binding advertisements for the FEC are constrained by the negotiated label advertisement mode or not. Furthermore, this document specifies the label advertisement mode to be used for all currently defined FECs.
FEC的标签绑定广告是否受协商标签广告模式的约束。此外，本文件规定了用于所有当前定义的FEC的标签广告模式。
To remove any ambiguity and conflict regarding a label advertisement discipline among different FEC types sharing a common LDP session, this document specifies a label advertisement discipline for FEC types.
为了消除共享公共LDP会话的不同FEC类型之间关于标签广告规程的任何歧义和冲突，本文档指定了FEC类型的标签广告规程。
This document introduces the following types for specifying a label advertisement discipline for a FEC type:
本文档介绍了以下类型，用于为FEC类型指定标签广告规程：
- DU (Downstream Unsolicited) - DoD (Downstream on Demand) - As negotiated (DU or DoD) - Upstream ([RFC6389]) - Not applicable - Unknown
- DU（下游未经请求）-国防部（下游按需）-协商（DU或国防部）-上游（[RFC6389]）-不适用-未知
Section 3.5.3 of [RFC5036] is updated to add the following two statements under the description of "A, Label Advertisement Discipline":
更新了[RFC5036]第3.5.3节，在“A，标签广告规程”的描述下添加了以下两条声明：
- Each document defining an LDP FEC must state the applicability of the negotiated label advertisement discipline for label binding advertisements for that FEC. If the negotiated label advertisement discipline does not apply to the FEC, the document must also explicitly state the discipline to be used for the FEC.
- 每个定义LDP FEC的文件必须说明协商标签广告规程对该FEC标签绑定广告的适用性。如果协商标签广告规程不适用于FEC，则文件还必须明确说明FEC使用的规程。
- This document defines the label advertisement discipline for the following FEC types:
- 本文件定义了以下FEC类型的标签广告规程：
+----------+----------+--------------------------------+
| FEC Type | FEC Name | Label Advertisement Discipline |
+----------+----------+--------------------------------+
| 0x01 | Wildcard | Not applicable |
| 0x02 | Prefix | As negotiated (DU or DoD) |
+----------+----------+--------------------------------+
+----------+----------+--------------------------------+
| FEC Type | FEC Name | Label Advertisement Discipline |
+----------+----------+--------------------------------+
| 0x01 | Wildcard | Not applicable |
| 0x02 | Prefix | As negotiated (DU or DoD) |
+----------+----------+--------------------------------+
The label advertisement discipline for currently defined LDP FEC types is listed in Section 4.
第4节列出了当前定义的LDP FEC类型的标签广告规程。
This document updates the respective RFCs in which these FECs are introduced and defined.
本文件更新了引入和定义这些FEC的各个RFC。
This document only clarifies the applicability of an LDP session's label advertisement mode and hence does not add any LDP security mechanics and considerations to those already defined in the LDP specification [RFC5036].
本文件仅澄清了LDP会话的标签广告模式的适用性，因此未在LDP规范[RFC5036]中已经定义的LDP安全机制和注意事项中添加任何LDP安全机制和注意事项。
This document mandates the specification of a label advertisement discipline for each defined FEC type and hence IANA's "Forwarding Equivalence Class (FEC) Type Name Space" registry under IANA's "Label Distribution Protocol (LDP) Parameters" registry has been extended as follows:
本文件要求为每个定义的FEC类型指定标签广告规程，因此IANA的“标签分发协议（LDP）参数”注册表下的IANA“转发等价类（FEC）类型名称空间”注册表扩展如下：
- Added a new column titled "Label Advertisement Discipline" with the following possible values:
- 添加了一个标题为“标签广告规则”的新列，包含以下可能值：
o DU o DoD o As negotiated (DU or DoD) o Upstream o Not applicable o Unknown
o DU o国防部o协商（DU或国防部）o上游o不适用o未知
- Made this document an additional reference for the registry itself and for all affected registrations.
- 使本文件成为注册中心本身和所有受影响注册的附加参考。
- Kept other columns of the registry in place and populated as they were.
- 保留注册表的其他列并按原样填充。
For the currently assigned FEC types, the updated registry looks like:
对于当前分配的FEC类型，更新的注册表如下所示：
+=====+====+===============+==============+===========+============+
|Value|Hex | Name |Label | Reference |Notes/ |
| | | |Advertisement | |Registration|
| | | |Discipline | |Date |
+=====+====+===============+==============+===========+============+
| 0 |0x00|Reserved | | | |
+-----+----+---------------+--------------+-----------+------------+
| 1 |0x01|Wildcard |Not applicable| [RFC5036] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 2 |0x02|Prefix |As negotiated | [RFC5036] | |
| | | |(DU or DoD) | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 4 |0x04|CR-LSP |DoD | [RFC3212] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 5 |0x05|Typed Wildcard |Not applicable| [RFC5918] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 6 |0x06|P2MP |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 7 |0x07|MP2MP-up |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 8 |0x08|MP2MP-down |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 9 |0x09|HSMP-upstream |DU | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 10 |0x0A|HSMP-downstream|DU, Upstream | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 128 |0x80|PWid |DU | [RFC4447] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 129 |0x81|Generalized |DU | [RFC4447] | |
| | |PWid | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
| 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 |
| | |Upstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
+=====+====+===============+==============+===========+============+
|Value|Hex | Name |Label | Reference |Notes/ |
| | | |Advertisement | |Registration|
| | | |Discipline | |Date |
+=====+====+===============+==============+===========+============+
| 0 |0x00|Reserved | | | |
+-----+----+---------------+--------------+-----------+------------+
| 1 |0x01|Wildcard |Not applicable| [RFC5036] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 2 |0x02|Prefix |As negotiated | [RFC5036] | |
| | | |(DU or DoD) | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 4 |0x04|CR-LSP |DoD | [RFC3212] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 5 |0x05|Typed Wildcard |Not applicable| [RFC5918] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 6 |0x06|P2MP |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 7 |0x07|MP2MP-up |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 8 |0x08|MP2MP-down |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 9 |0x09|HSMP-upstream |DU | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 10 |0x0A|HSMP-downstream|DU, Upstream | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 128 |0x80|PWid |DU | [RFC4447] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 129 |0x81|Generalized |DU | [RFC4447] | |
| | |PWid | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
| 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 |
| | |Upstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
+-----+----+---------------+--------------+-----------+------------+
| 131 |0x83|Protection |DU |[FAST-PROT]| 2010-02-26 |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 132 |0x84|P2MP PW |DU | [P2MP-PW] | 2014-04-04 |
| | |Downstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
+-----+----+---------------+--------------+-----------+------------+
| 131 |0x83|Protection |DU |[FAST-PROT]| 2010-02-26 |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 132 |0x84|P2MP PW |DU | [P2MP-PW] | 2014-04-04 |
| | |Downstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
[RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002, <http://www.rfc-editor.org/info/rfc3212>.
[RFC3212]Jamoussi，B.，Ed.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 32122002年1月<http://www.rfc-editor.org/info/rfc3212>.
[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, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010, <http://www.rfc-editor.org/info/rfc5918>.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 59182010年8月<http://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, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011, <http://www.rfc-editor.org/info/rfc6389>.
[RFC6389]阿加瓦尔，R.和JL。Le Roux，“LDP的MPLS上游标签分配”，RFC 63892011年11月<http://www.rfc-editor.org/info/rfc6389>.
[RFC7140] Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP Extensions for Hub and Spoke Multipoint Label Switched Path", RFC 7140, March 2014, <http://www.rfc-editor.org/info/rfc7140>.
[RFC7140]Jin，L.，Jounay，F.，Wijnands，IJ.，和N.Leymann，“中心辐射多点标签交换路径的LDP扩展”，RFC 7140，2014年3月<http://www.rfc-editor.org/info/rfc7140>.
[FAST-PROT] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW Endpoint Fast Failure Protection", Work in Progress, draft-ietf-pwe3-endpoint-fast-protection-01, July 2014.
[FAST-PROT]Shen，Y.，Aggarwal，R.，Henderickx，W.，和Y.Jiang，“PW端点快速故障保护”，正在进行的工作，草稿-ietf-pwe3-端点-FAST-Protection-012014年7月。
[P2MP-PW] Sivabalan, S., Ed., Boutros, S., Ed., Martini, L., Konstantynowicz, M., Del Vecchio, G., Nadeau, T., Jounay, F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., Delord, S., and K. Raza, "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Work in Progress, draft-ietf-pwe3-p2mp-pw-04, March 2012.
[P2MP-PW]Sivabalan，S.，Ed.，Boutros，S.，Ed.，Martini，L.，Konstantynowicz，M.，Del Vecchio，G.，Nadeau，T.，Jounay，F.，Niger，P.，Kamite，Y.，Jin，L.，Vigoureux，M.，Ciavglia，L.，Delord，S.，和K.Raza，“使用LDP发送根发起的点对多点伪线”，正在进行的工作，草案-ietf-pwe3-P2MP-PW-04，2012年3月。
Acknowledgments
致谢
We acknowledge Eric Rosen and Rajiv Asati for their initial review and input on the document.
我们感谢Eric Rosen和Rajiv Asati对文件的初步审查和投入。
Authors' Addresses
作者地址
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
Kamran Raza Cisco Systems，Inc.位于加拿大渥太华K2K-3E8的创新大道2000号
EMail: skraza@cisco.com
EMail: skraza@cisco.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134
EMail: sboutros@cisco.com
EMail: sboutros@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 United States
Luca Martini Cisco Systems，Inc.美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 Germany
Nicolai Leymann德国电信公司Winterfeldtstrasse 21柏林10781德国
EMail: N.Leymann@telekom.de
EMail: N.Leymann@telekom.de