Network Working Group P. Ashwood-Smith, Editor
Request for Comments: 3472 Nortel Networks
Category: Standards Track L. Berger, Editor
Movaz Networks
January 2003
Network Working Group P. Ashwood-Smith, Editor
Request for Comments: 3472 Nortel Networks
Category: Standards Track L. Berger, Editor
Movaz Networks
January 2003
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.
本文档描述了支持通用MPLS所需的基于多协议标签交换（MPLS）约束的路由标签分发协议（CR-LDP）信令的扩展。广义MPLS扩展了MPLS控制平面，以涵盖时分（例如，同步光网络和同步数字体系、SONET/SDH）、波长（光lambda）和空间交换（例如，输入端口或光纤到输出端口或光纤）。本文档介绍了扩展的CR-LDP特定描述。通用功能说明可在单独的文档中找到。
Table of Contents
目录
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 23
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 23
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [RFC3471]. This document presents CR-LDP specific formats and mechanisms needed to support all four classes of interfaces. RSVP-TE extensions can be found in [RFC3473].
广义MPLS将MPLS从支持分组（PSC）接口和交换扩展到支持三类新的接口和交换：时分复用（TDM）、Lambda交换机（LSC）和光纤交换机（FSC）。[RFC3471]中提供了支持新型接口和交换所需的MPLS信令扩展的功能描述。本文档介绍了支持所有四类接口所需的CR-LDP特定格式和机制。RSVP-TE扩展可在[RFC3473]中找到。
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. It should be noted that the RSVP-TE specific version of Generalized MPLS includes RSVP specific support for rapid failure notification, see Section 4 [RFC3473]. For CR-LDP there is not currently a similar mechanism. When a failure is detected it will be propagated with RELEASE/WITHDRAW messages radially outward from the point of failure. Resources are to be released in this phase and actual resource information may be fed back to the source using a feedback mechanisms.
[RFC3471]应视为本文件的配套文件。本文件的格式与[RFC3471]相似。应注意的是，通用MPLS的RSVP-TE特定版本包括对快速故障通知的RSVP特定支持，参见第4节[RFC3473]。对于CR-LDP，目前还没有类似的机制。当检测到故障时，将从故障点径向向外传播释放/收回消息。在此阶段将释放资源，并使用反馈机制将实际资源信息反馈给源。
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]中所述进行解释。
This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
本节定义了通用标签请求、通用标签、波段切换支持、建议标签和标签集的格式。
A REQUEST message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request Type, Length, and Value (TLV) is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The Switching Type field may also be updated hop-by-hop.
请求消息应尽可能包含特定的LSP（标签交换路径）编码类型，以允许通过传输LSR实现最大的切换灵活性。通用标签请求类型、长度和值（TLV）由入口节点设置，由传输节点透明传递，并由出口节点使用。交换类型字段也可以逐跳更新。
The format of a Generalized Label Request is:
通用标签请求的格式为：
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| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
A node processing a REQUEST message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and by the outgoing interface. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked.
处理包含通用标签请求的请求消息的节点必须验证传入接口、节点和传出接口是否能够满足所请求的参数。节点可以直接支持LSP，也可以使用隧道（FA），即另一类交换。无论哪种情况，都必须检查每个参数。
Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER (Explicit Route) hops when using tunnels see [MPLS-HIERARCHY].
请注意，本地节点策略规定了何时可以使用隧道以及何时可以创建隧道。当地政策可能允许动态建立隧道，也可能仅受行政控制。有关隧道和使用隧道时ER（显式路由）跃点处理的更多信息，请参阅[MPLS-HIERARCHY]。
Transit and egress nodes MUST verify that the node itself and, where appropriate, that the outgoing interface or tunnel can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Encoding" indication.
传输和出口节点必须验证节点本身以及（在适当情况下）输出接口或隧道是否支持请求的LSP编码类型。如果无法支持编码，则节点必须生成通知消息，并带有“路由问题/不支持的编码”指示。
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a NOTIFICATION message with a "Routing problem/Switching Type" indication.
节点必须验证相应的传入接口是否支持Switching type参数中指示的类型。如果无法支持该类型，则节点必须生成一条带有“路由问题/切换类型”指示的通知消息。
The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported G-PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID during the processing of the MAPPING message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
G-PID参数通常仅在出口处检查。如果指示的G-PID不受支持，则出口必须生成通知消息，并带有“路由问题/不支持的G-PID”指示。在PSC的情况下，当请求倒数第二个跃点弹出（PHP）时，倒数第二个跃点还在处理映射消息期间检查（存储的）G-PID。在这种情况下，如果不支持G-PID，则倒数第二个跃点必须生成带有“路由问题/不可接受标签值”指示的通知消息。生成的通知消息可能包括可接受的标签集，请参见第4节。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a REQUEST message being propagated. In the egress case and PHP special case this will typically result in a MAPPING message being generated.
未生成错误消息时，将进行正常处理。在传输情况下，这通常会导致传播请求消息。在出口情况和PHP特殊情况下，这通常会导致生成映射消息。
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak and Committed Data Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently.
带宽编码在CR-LDP业务参数TLV中进行。有关用于特定信号类型的值的定义，请参见[RFC3471]。这些值在流量参数TLV的峰值和提交数据速率字段中设置。TLV中的其他带宽/服务相关参数将被忽略并透明地携带。
The format of a Generalized Label is:
通用标签的格式为：
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| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
有关参数和标签编码的说明，请参见[RFC3471]。
The Generalized Label travels in the upstream direction in MAPPING messages.
通用标签在映射消息中沿上游方向移动。
The presence of both a generalized and normal label TLV in a MAPPING message is a protocol error and should treated as a malformed message by the recipient.
映射消息中同时存在通用和普通标签TLV是协议错误，收件人应将其视为格式错误的消息。
The recipient of a MAPPING message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
包含通用标签的映射消息的收件人验证传递的值是否可接受。如果标签不可接受，则收件人必须生成带有“路由问题/MPLS标签分配失败”指示的通知消息。生成的通知消息可能包括可接受的标签集，请参见第4节。
Waveband switching uses the same format as the generalized label, see section 2.2. The type 0x0828 is assigned for the Waveband Label.
波段切换使用与通用标签相同的格式，见第2.2节。为波段标签指定了类型0x0828。
In the context of waveband switching, the generalized label has the following format:
在波段切换的情况下，通用标签具有以下格式：
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| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable.
第2.2.1节中定义的程序适用于波段切换。这包括如果任何标签字段无法识别或不可接受，则生成带有“路由问题/MPLS标签分配失败”指示的通知消息。
Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed,
此外，当一个波段切换到另一个波段时，该波段内的波长可能会围绕中心频率进行镜像。当使用这种类型的开关时，
the start and end label in the waveband label TLV MUST be swapped before forwarding the label TLV with the new waveband Id. In this manner an egress/ingress LSR that receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. Without this mechanism and with an odd number of mirrored switching operations, the egress LSRs will not know that an input wavelength of say L1 will emerge from the waveband tunnel as L100.
在使用新的波段Id转发标签TLV之前，必须交换波段标签TLV中的起始标签和结束标签。通过这种方式，接收这些值反转的波段标签的出/入LSR知道，它还必须反转其出关联以拾取正确的波长。如果没有该机制并且具有奇数个镜像开关操作，则出口lsr将不知道所述L1的输入波长将作为L100从波段隧道中出现。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
当建立双向波段隧道时，必须在两个方向上执行此操作。
The format of a suggested label is identical to a generalized label. It is used in REQUEST messages. Suggested Label uses type = 0x904.
建议标签的格式与通用标签相同。它用于请求消息中。建议的标签使用类型=0x904。
Errors in received Suggested Labels MUST be ignored. This includes any received inconsistent or unacceptable values.
必须忽略收到的建议标签中的错误。这包括收到的任何不一致或不可接受的值。
Per [RFC3471], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes corresponding a label upstream.
根据[RFC3471]，如果下游节点传递的标签值与建议的上游标签不同，则上游LSR必须重新配置自身，以便使用下游节点指定的标签，或生成带有“路由问题/不可接受标签值”指示的通知消息。此外，入口节点不应使用建议的标签发送数据流量，直到下游节点通过相应的上游标签。
The format of a Label Set is:
标签集的格式为：
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| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
标签类型：14位
Indicates the type and format of the labels carried in the TLV. Values match the TLV type of the appropriate Label TLV.
指示TLV中携带的标签的类型和格式。值与相应标签TLV的TLV类型匹配。
See [RFC3471] for a description of other parameters.
有关其他参数的说明，请参见[RFC3471]。
A Label Set is defined via one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. When the Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
标签集通过一个或多个标签集TLV定义。可以分别通过动作零（0）和一（1）个TLV向标签集添加或从标签集中排除特定标签/子通道。标签/子通道的范围可分别通过动作二（2）和三（3）TLV添加到标签集或从标签集中排除。当标签集TLV仅列出要排除的标签/子通道时，这意味着可以接受所有其他标签。
The absence of any Label Set TLVs implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream.
没有任何标签集TLV意味着所有标签都是可接受的。当节点希望限制可在下游使用的标签时，将包括标签集。
On reception of a REQUEST message, the receiving node will restrict its choice of labels to one, which is in the Label Set. Nodes capable of performing label conversion may also remove the Label Set prior to forwarding the REQUEST message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label Set TLVs, then the request is terminated and a NOTIFICATION message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the MAPPING message or if the selection is made immediately for propagation in the MAPPING message.
在接收到请求消息时，接收节点将其标签选择限制为标签集中的一个标签。能够执行标签转换的节点还可以在转发请求消息之前移除标签集。如果节点无法从标签集拾取标签，或者如果解析标签集TLV时出现问题，则请求将终止，并且必须生成带有“路由问题/标签集”指示的通知消息。如果存储标签集以供以后在映射消息上选择，或者如果立即进行选择以在映射消息中传播，则这是一个局部问题。
On reception of a REQUEST message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a REQUEST message. When the resulting Label Set is empty, the REQUEST must be terminated, and a NOTIFICATION message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists.
在接收到请求消息时，将消息中表示的标签集与下游接口处的可用标签集进行比较，并在请求消息中转发生成的相交标签集。当生成的标签集为空时，必须终止请求，并生成通知消息和“路由问题/标签集”指示。注意，交叉点基于物理标签（实际波长/波段值），这些物理标签在不同链路上可能具有不同的逻辑值，因此，节点有责任映射这些值，以便它们具有一致的物理含义，或者，如果不存在合适的逻辑标签值，则从集合中删除特定值。
When processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
在中间节点处理映射消息时，向上游传播的标签必须位于标签集内。
Note, on reception of a MAPPING message a node that is incapable of performing label conversion has no other choice than to use the same physical label (wavelength/band) as received in the MAPPING message. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail.
注意，在接收到映射消息时，不能执行标签转换的节点除了使用在映射消息中接收到的相同物理标签（波长/频带）之外别无选择。在这种情况下，标签集的使用和传播将显著减少分配失败的机会。
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the REQUEST message. An Upstream Label has the same format as the generalized label, see Section 2.2. Upstream Label uses type = 0x0826.
双向LSP设置由请求消息中的上游标签表示。上游标签的格式与通用标签相同，见第2.2节。上游标签使用类型=0x0826。
The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream Label is added to the REQUEST message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the REQUEST message is sent.
建立双向LSP的过程在建立带有一些附加的单向LSP之后进行。为了支持双向LSP，向请求消息添加了一个上游标签。上游标签必须指示在发送请求消息时可有效转发的标签。
When a REQUEST message containing an Upstream Label is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4.
当接收到包含上游标签的请求消息时，接收器首先验证上游标签是可接受的。如果标签不可接受，接收方必须发出带有“路由问题/不可接受标签值”指示的通知消息。生成的通知消息可能包括可接受的标签集，请参见第4节。
An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing Upstream Label and propagating the REQUEST message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a NOTIFICATION message with a "Routing problem/Label allocation failure" indication.
中间节点还必须在输出接口上分配标签，并在填充输出上游标签和传播请求消息之前建立内部数据路径。如果中间节点无法分配标签或内部资源，则必须发出带有“路由问题/标签分配失败”指示的通知消息。
Terminator nodes process REQUEST messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
终止节点像往常一样处理请求消息，但上游标签可立即用于将与LSP上游相关联的数据通信量传输到启动器。
When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels.
删除双向LSP时，上游和下游标签都将失效，并且使用关联标签发送数据不再有效。
This section defines the Acceptable Label Set TLV to support Notification on Label Error per [RFC3471]. An Acceptable Label Set TLV uses a type value of 0x082a. The remaining contents of the TLV have the identical format as the Label Set TLV, see Section 2.5.
本节根据[RFC3471]定义可接受的标签集TLV，以支持标签错误通知。可接受的标签集TLV使用类型值0x082a。TLV的其余内容与标签集TLV的格式相同，见第2.5节。
Acceptable Label Set TLVs may be carried in NOTIFICATION messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.5.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable Label Set TLVs. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) TLVs respectively. When the Acceptable Label Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable.
可接受的标签集TLV可在通知消息中携带。定义可接受标签集的程序遵循定义标签集的程序，见第2.5.1节。具体而言，通过一个或多个可接受标签集TLV定义可接受标签集。特定标签/子通道可分别通过操作零（0）和一（1）个TLV添加到可接受标签集或从中排除。标签/子通道的范围可分别通过操作二（2）和三（3）个TLV添加到可接受的标签集或从中排除。当可接受标签集TLV仅列出要排除的标签/子通道时，这意味着所有其他标签都是可接受的。
The inclusion of Acceptable Label Set TLVs is optional. If included, the NOTIFICATION message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable Label Set TLVs does not have any specific meaning.
包含可接受的标签集TLV是可选的。如果包含，通知消息应包含“路由问题/不可接受的标签值”指示。没有可接受的标签集TLV没有任何具体含义。
The Label ER-Hop TLV is defined as follows:
标签ER Hop 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 (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
有关L、U和标签参数的说明，请参见[RFC3471]。
The Label ER-Hop follows a ER-Hop containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. Up to two label ER-Hops may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE" errors:
标签ER-Hop跟随一个ER-Hop，该ER-Hop包含与要使用它的链路相关联的IP地址或接口标识符[MPLS-UNNUM]。最多可存在两个标签ER跳，一个用于下游标签，一个用于上游标签。以下情况应导致“错误的显式路由”错误：
o If the first label ER-Hop is not preceded by a ER-Hop containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. o For a label ER-Hop to follow a ER-Hop that has the L-bit set. o On unidirectional LSP setup, for there to be a label ER-Hop with the U-bit set. o For there to be two label ER-Hops with the same U-bit values.
o 如果第一个标签ER Hop前面没有包含IP地址的ER Hop或与输出链路相关联的接口标识符[MPLS-UNNUM]。o标签ER Hop跟随具有L位设置的ER Hop。o在单向LSP设置上，有一个U位设置的标签ER跃点。o表示存在两个具有相同U位值的标签ER跃点。
To support the label ER-Hop, a node must check to see if the ER-Hop following its associate address/interface is a label ER-Hop. If it is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops for bidirectional LSPs. If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label Set TLV. This Label Set TLV MUST be included on the corresponding outgoing REQUEST message.
为了支持标签ER-Hop，节点必须检查其关联地址/接口后面的ER-Hop是否是标签ER-Hop。如果是，则检查单向LSP的一个ER跳和双向LSP的两个ER跳。如果正在检查的ER跃点的U位为清除（0），则标签的值将复制到新的标签集TLV中。此标签集TLV必须包含在相应的传出请求消息中。
If the U-bit of the ER-Hop being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream Label TLV. This Upstream Label TLV MUST be included on the corresponding outgoing REQUEST message.
如果被检查的ER跳的U位被设置为（1），则标签的值是用于与双向LSP相关联的上游业务的标签。如果此标签不可接受，则应生成“错误显式路由”错误。如果标签可接受，则将标签复制到新的上游标签TLV中。此上游标签TLV必须包含在相应的传出请求消息中。
After processing, the label ER-Hops are removed from the ER.
处理后，标签ER跳从ER中移除。
Note an implication of the above procedures is that the label ER-Hop should never be the first ER-Hop in a newly received message. If the label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be treated as a "Bad strict node" error.
注：上述过程的一个含义是，标签ER Hop不应是新接收消息中的第一个ER Hop。如果标签ER Hop是接收到的ER的第一个ER Hop，则应将其视为“错误严格节点”错误。
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label ER-Hop are outside the scope of this document.
LSP前端的LSR获取构建标签ER Hop所需信息的过程不在本文档范围内。
The use of the Protection TLV is optional. The TLV is included to indicate specific protection attributes of an LSP.
保护TLV的使用是可选的。TLV用于指示LSP的特定保护属性。
The format of Protection Information TLV is:
保护信息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| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
Transit nodes processing a REQUEST message containing a Protection TLV MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Link Protection" indication.
处理包含保护TLV的请求消息的传输节点必须验证传出接口或隧道（FA）是否能够满足请求的保护。如果不能，则节点必须生成通知消息，并带有“路由问题/不支持的链路保护”指示。
Administrative Status Information is carried in the Admin Status TLV. The TLV provides information related to the administrative state of a particular LSP. The information is used in two ways. In the first, the TLV is carried in REQUEST and MAPPING messages to indicate the administrative state of an LSP. In the second, the TLV is carried in Notification message to request a change to the administrative state of an LSP.
管理状态信息包含在管理状态TLV中。TLV提供与特定LSP的管理状态相关的信息。这些信息有两种用途。在第一种情况下，TLV携带在请求和映射消息中，以指示LSP的管理状态。在第二种情况下，在通知消息中携带TLV，以请求更改LSP的管理状态。
The use of the Admin Status TLV is optional. It uses Type = 0x082b. The format of the TLV is:
管理员状态TLV的使用是可选的。它使用类型=0x082b。TLV的格式为：
The format of Admin Status TLV in REQUEST, MAPPING and Notification Messages is:
请求、映射和通知消息中的管理员状态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| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
The Admin Status TLV is used to notify each node along the path of the status of the LSP. Each node processes status information based on local policy and then propagated in the corresponding outgoing messages. The TLV is inserted in REQUEST messages at the discretion of the ingress node. The absence of the TLV is the equivalent to receiving a TLV containing values all set to zero.
管理状态TLV用于通知路径上的每个节点LSP的状态。每个节点根据本地策略处理状态信息，然后在相应的传出消息中传播。TLV由入口节点自行决定插入请求消息中。缺少TLV相当于接收一个包含所有设置为零的值的TLV。
Transit nodes receiving a REQUEST message containing an Admin Status TLV, update their local state, take any appropriate local action based on the indicated status and then propagate the received Admin Status TLV in the outgoing REQUEST message.
接收包含管理员状态TLV的请求消息的传输节点，更新其本地状态，根据指示的状态采取任何适当的本地操作，然后在传出请求消息中传播接收到的管理员状态TLV。
Edge nodes receiving a REQUEST message containing an Admin Status TLV, also update their local state and take any appropriate local action based on the indicated status. When the ADMIN Status TLV is received with the R bit set, the receiving edge node should reflect the received values in a corresponding MAPPING message. Specifically, if an egress node receives a Request message with the R bit of the Admin_Status TLV set and the node the node SHOULD send a Mapping message containing an Admin_Status TLV with the same values set, with the exception of the R bit, as received in the corresponding Request message.
接收到包含管理状态TLV的请求消息的边缘节点也会更新其本地状态，并根据指示的状态采取任何适当的本地操作。当通过设置R位接收管理状态TLV时，接收边缘节点应在相应的映射消息中反映接收到的值。具体地说，如果出口节点接收到具有Admin_Status TLV集合的R位的请求消息，并且该节点应发送包含Admin_Status TLV的映射消息，该TLV具有与相应请求消息中接收到的相同的值集合（R位除外）。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down.
在某些情况下，尤其是在光纤网络中，在拆除LSP之前设置LSP的管理状态非常有用。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress:
在这种情况下，从入口删除LSP时应遵循以下程序：
o The ingress node precedes an LSP deletion by inserting an Admin Status TLV in a Notification Message setting the Reflect (R) and Delete (D) bits.
o 入口节点通过在设置反射（R）和删除（D）位的通知消息中插入管理状态TLV，在LSP删除之前进行。
o Transit nodes process the Admin Status TLV by passing the Notification message. The egress node May respond with a Notification message with the Admin Status TLV.
o 传输节点通过传递通知消息来处理管理状态TLV。出口节点可响应具有管理员状态TLV的通知消息。
o Upon receiving the Admin Status TLV with the Delete (D) bit set in the Notification message, the egress SHOULD respond with a LABEL WITHDRAW message and normal CR-LDP processing takes place.
o 在接收到管理员状态TLV以及通知消息中设置的删除（D）位后，出口应以标签撤回消息进行响应，并进行正常的CR-LDP处理。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress:
在这种情况下，从出口删除LSP时应遵循以下程序：
o The egress node indicates its desire for deletion by inserting an Admin Status TLV in a Notification message and setting Delete (D) bit.
o 出口节点通过在通知消息中插入Admin Status TLV并设置Delete（D）位来指示其删除愿望。
o Transit nodes process the Admin Status TLV as described above.
o 传输节点如上所述处理管理状态TLV。
o Upon receiving the Admin Status TLV with the Delete (D) bit set in the Notification message, the ingress node sends a LABEL RELEASE message downstream to remove the LSP and normal CR-LDP processing takes place.
o 在接收到在通知消息中设置了Delete（D）位的管理状态TLV后，入口节点向下游发送标签释放消息以移除LSP，并进行正常的CR-LDP处理。
Subsequent messaging Admin Status messaging may be performed by Notification Messages. The ingress may begin the propagation of a Notification Message with an Admin Status TLV. Each subsequent node propagates the Notification with the Admin Status TLV from the ingress to the egress and then the egress node returns the Notification messages back Upstream carrying the Admin Status TLV.
后续消息管理状态消息可以通过通知消息执行。入口可开始传播具有管理员状态TLV的通知消息。每个后续节点将带有管理状态TLV的通知从入口传播到出口，然后出口节点将带有管理状态TLV的通知消息返回上游。
Intermediate and egress nodes may trigger the setting of administrative status via the use of Notification messages. To accomplish this, an intermediate or egress node generates a Notification message with the corresponding upstream notify session information. The Admin Status TLV MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set.
中间和出口节点可通过使用通知消息触发管理状态的设置。为此，中间或出口节点生成具有相应上游通知会话信息的通知消息。管理状态TLV必须包含在会话信息中，并设置适当的位。不得设置反射（R）位。
An ingress or egress node receiving a Notification message containing an Admin Status TLV with the Delete (D) bit set, SHOULD initiate the deletion procedure described in the previous section.
入口或出口节点接收到包含管理员状态TLV的通知消息并设置了删除（D）位，应启动上一节中描述的删除过程。
Some special processing is required in order to cover the case of nodes that do not support the Admin Status TLV and other error conditions. Specifically, a node that sends a Notification message containing an Admin Status TLV with the Down (D) bit set MUST verify that it receives a corresponding LABEL RELEASE message within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node does not receive such a LABEL RELEASE message, it SHOULD send a Label Release message downstream and a LABEL WITHDRAW message upstream.
需要进行一些特殊处理，以涵盖不支持Admin Status TLV和其他错误条件的节点的情况。具体而言，发送包含管理员状态TLV且设置了Down（D）位的通知消息的节点必须验证其是否在可配置的时间段内收到相应的标签释放消息。默认情况下，此时间段应为30秒。如果节点没有收到这样的标签释放消息，它应该向下游发送标签释放消息，向上游发送标签撤回消息。
This section provides the protocol specific formats and procedures to required support a control channel not being in-band with a data channel.
本节提供了协议特定格式和程序，以支持不在数据通道频带内的控制通道。
The choice of the data interface to use is always made by the sender of the REQUEST message. The choice of the data interface is indicated by the sender of the REQUEST message by including the data channel's interface identifier in the message using a new Interface TLV type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the REQUEST sender explicitly identifies the component interface used in each direction.
要使用的数据接口的选择始终由请求消息的发送者进行。数据接口的选择由请求消息的发送方通过使用新接口TLV类型在消息中包括数据通道的接口标识符来指示。对于双向LSP，发送方选择每个方向的数据接口。在除捆绑之外的所有情况下，上游接口由下游接口暗示。对于捆绑，请求发送方明确标识在每个方向上使用的组件接口。
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is:
请求、映射消息中IPV4接口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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is:
请求、映射消息中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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
See [RFC3212] for a description of signaling address. See [RFC3471] for a description of parameters and encoding of TLVs.
有关信令地址的说明，请参见[RFC3212]。有关TLV的参数和编码说明，请参见[RFC3471]。
An IF_ID TLV is used on links where there is not a one-to-one association of a control channel to a data channel, see [RFC3471].
在控制信道与数据信道之间没有一对一关联的链路上使用IF_ID TLV，请参阅[RFC3471]。
The LDP session uses the IF_ID TLV to identify the data channel(s) associated with the LSP. For a unidirectional LSP, a downstream data channel MUST be indicated. For bidirectional LSPs, a common downstream and upstream data channel is normally indicated. In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from the upstream data channel. Data channels are specified from the viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD NOT be used when no TLVs are needed.
LDP会话使用IF_ID TLV来识别与LSP相关联的数据信道。对于单向LSP，必须指示下游数据通道。对于双向LSP，通常指示一个公共的下行和上行数据信道。在穿越捆绑链路的双向LSP的特殊情况下，可以指定不同于上游数据信道的下游数据信道。数据通道是从请求消息的发送者的角度指定的。如果不需要TLV，则不应使用IF_ID TLV。
A node receiving one or more IF_ID TLVs in a REQUEST message saves their values and returns them in the subsequent MAPPING message sent to the node that originated the TLVs.
在请求消息中接收一个或多个IF_ID TLV的节点保存它们的值，并在发送到发起TLV的节点的后续映射消息中返回它们。
Note, the node originating an IF_ID TLV MUST ensure that the selected outgoing interface, as specified in the IF_ID TLV, is consistent with an ERO. A node that receives an IF_ID TLV SHOULD check whether the information carried in this TLV is consistent with the information carried in a received ERO, and if not it MUST send a LABEL ABORT Message with the error code "Routing Error" and error value of "Bad Explicit Routing TLV Error" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
注意，发起IF_ID TLV的节点必须确保IF_ID TLV中指定的选定传出接口与ERO一致。接收IF_ID TLV的节点应检查此TLV中携带的信息是否与接收到的ERO中携带的信息一致，如果不一致，则必须向发送方发送带有错误代码“路由错误”和错误值“错误显式路由TLV错误”的标签中止消息。当初始ERO子对象不是传入接口时，无法执行此检查。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID Status TLV are defined.
在某些情况下，指示与错误关联的特定接口很有用。为了支持这些情况，定义了IF_ID状态TLV。
The format of the IPv4 IF_ID Status TLV is:
IPv4 IF_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID Status TLV is:
IPv6 IF_ID Status 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| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3036] for a description of status code value fields. See [RFC3471] for a description of parameters and encoding of TLVs.
有关状态代码值字段的说明，请参见[RFC3036]。有关TLV的参数和编码说明，请参见[RFC3471]。
Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID Status TLV in the corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status TLV SHOULD be generated and processed as any other Status TLV, see [RFC3036].
希望指示错误与特定接口相关的节点应在相应的标签撤消或标签释放消息中使用适当的IF_ID Status TLV。如果ID状态TLV应作为任何其他状态TLV生成和处理，请参阅[RFC3036]。
In optical transport networks, failures in the out-of-fiber signaling communication or optical control plane should not have service impact on the existing optical connections. Under such circumstances, a mechanism MUST exist to detect a signaling communication failure and a recovery procedure SHALL guarantee connection integrity at both ends of the signaling channel.
在光传输网络中，光纤外信令通信或光控制平面中的故障不应对现有光连接产生服务影响。在这种情况下，必须存在检测信令通信故障的机制，并且恢复程序应保证信令信道两端的连接完整性。
The LDP Fault tolerant document [LDP-FT] specifies the procedures for recovering LDP and CR-LDP sessions under failure. Please refer to his document for procedures on recovering optical connections. Currently the Fault tolerant document covers many of the common failure modes for a separated control and data plane.
LDP容错文件[LDP-FT]规定了在故障情况下恢复LDP和CR-LDP会话的程序。有关恢复光纤连接的步骤，请参阅他的文档。目前，容错文档涵盖了分离控制和数据平面的许多常见故障模式。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
本文件是众多作者的作品，由该领域以前的许多文件组成。
Valuable comments and input were received from a number of people, notably Adrian Farrel.
许多人都提出了宝贵的意见和建议，尤其是阿德里安·法雷尔。
This document introduces no new security considerations to [RFC3212].
本文档未向[RFC3212]引入新的安全注意事项。
This document uses the LDP [RFC3036] name spaces, see http://www.iana.org/assignments/ldp-namespaces, which lists the assignments for the following TLVs:
本文档使用LDP[RFC3036]名称空间，请参阅http://www.iana.org/assignments/ldp-namespaces，其中列出了以下TLV的分配：
o Generalized Label Request (TLV 0x0824) o Generalized Label (TLV 0x0825) o Upstream Label (TLV 0x0826) o Label Set (TLV 0x0827) o Waveband Label (TLV 0x0828) o ER-Hop (TLV 0x0829) o Acceptable Label Set (TLV 0x082a) o Admin Status (TLV 0x082b) o Interface ID (TLV 0x082c) o IPV4 Interface ID (TLV 0x082d) o IPV6 Interface ID (TLV 0x082e) o IPv4 IF_ID Status (TLV 0x082f) o IPv6 IF_ID Status (TLV 0x0830) o Protection (TLV 0x0835)
o 通用标签请求（TLV 0x0824）o通用标签（TLV 0x0825）o上游标签（TLV 0x0826）o标签集（TLV 0x0827）o波段标签（TLV 0x0828）o ER Hop（TLV 0x0829）o可接受标签集（TLV 0x082a）o管理状态（TLV 0x082b）o接口ID（TLV 0x082c）o IPV4接口ID（TLV 0x082d）o IPV6接口ID（TLV 0x082e）o IPv4 IF_ID状态（TLV 0x082f）o IPv6 IF_ID状态（TLV 0x0830）o保护（TLV 0x0835）
This section is taken from Section 10.4 of [RFC2026].
本节摘自[RFC2026]第10.4节。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[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月。
[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月。
[RFC3212] Jamoussi, B., 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.
[RFC3212]Jamoussi，B.，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 3212，2002年1月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，编辑，“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-LDP", Work in Progress.
[LDP-FT]Farrel，A.等人，“LDP和CR-LDP的容错”，正在进行的工作。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS-HIERARCHY]Kompella，K.和Y.Rekhter，“具有MPLS TE的LSP层次结构”，正在进行中。
[MPLS-UNNUM] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP", Work in Progress.
[MPLS-UNNUM]Kompella，K.，Rekhter，Y.和A.Kullberg，“在CR-LDP中发送未编号链接的信号”，工作正在进行中。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，编辑，“通用多协议标签交换（GMPLS）信令-资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood Smith Nortel Networks Corp.邮政信箱3511加拿大渥太华C站K1Y 4H7
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
加利福尼亚州圣何塞法拉利街5853号阿扬·班纳吉·卡里昂网络公司，邮编95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks，Inc.地址：弗吉尼亚州麦克莱恩市琼斯支路615号7926室，邮编：22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein EMail: gregb@grotto-networking.com
Greg Bernstein电子邮件：gregb@grotto-网络
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
延河Fan Axiowave Networks，Inc.马萨诸塞州马尔伯勒尼克松路200号，邮编01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821
Don Fedyk Nortel Networks Corp.600科技园马萨诸塞州比尔里卡01821
Phone: +1 978 288 3041
Fax: +1 978 288 0620
EMail: dwfedyk@nortelnetworks.com
Phone: +1 978 288 3041
Fax: +1 978 288 0620
EMail: dwfedyk@nortelnetworks.com
Jonathan P. Lang EMail: jplang@ieee.org
Jonathan P.Lang电子邮件：jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
Eric Mannie独立顾问，比利时布鲁塞尔富勒香松大道2号1050
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
巴拉·拉贾戈帕兰Tellium，Inc.新泽西州海洋港901号新月广场2号邮政信箱07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Debanjan Saha EMail: debanjan@acm.org
德班詹·萨哈电子邮件：debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
Vishal Sharma Metanoia，Inc.加利福尼亚州山景城别墅街1600号352单元，邮编94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
乔治斯沃诺思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.Bo Tang电子邮件：botang01@yahoo.com
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood Smith Nortel Networks Corp.邮政信箱3511加拿大渥太华C站K1Y 4H7
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks，Inc.地址：弗吉尼亚州麦克莱恩市琼斯支路615号7926室，邮编：22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。