Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 5710 LabN
Category: Standards Track D. Papadimitriou
ISSN: 2070-1721 Alcatel Lucent
JP. Vasseur
Cisco
January 2010
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 5710 LabN
Category: Standards Track D. Papadimitriou
ISSN: 2070-1721 Alcatel Lucent
JP. Vasseur
Cisco
January 2010
PathErr Message Triggered MPLS and GMPLS LSP Reroutes
PathErr消息触发MPLS和GMPLS LSP重路由
Abstract
摘要
This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values.
本文档描述了如何使用资源预留协议（RSVP）PathErr消息来触发多协议标签交换（MPLS）和通用MPLS（GMPLS）点到点流量工程（TE）标签交换路径（LSP）的重新路由，而无需首先移除LSP状态或资源。这种LSP重路由在许多情况下可能是可取的，例如，包括软抢占和正常关机。本文档描述了现有标准跟踪机制的使用，以支持LSP重新路由。在这种情况下，它依赖于已经定义为RSVP-TE一部分的机制，并简单地描述了要执行的操作序列。虽然现有协议定义可用于支持重路由应用程序，但本文档还定义了新的重路由特定错误代码，以允许将来定义重路由应用程序特定错误值。
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/rfc5710.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5710.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Reroute Requests ................................................4
2.1. Processing at Requesting Node ..............................4
2.1.1. Reroute Request Timeouts ............................5
2.2. Processing at Upstream Node ................................6
2.3. Processing at Ingress ......................................6
3. Example Reroute Requests ........................................7
3.1. Node Reroute Request .......................................7
3.2. Interface Reroute Request ..................................7
3.3. Component Reroute Request ..................................8
3.4. Label Reroute Request ......................................9
4. IANA Considerations .............................................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
7. Acknowledgments ................................................11
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Reroute Requests ................................................4
2.1. Processing at Requesting Node ..............................4
2.1.1. Reroute Request Timeouts ............................5
2.2. Processing at Upstream Node ................................6
2.3. Processing at Ingress ......................................6
3. Example Reroute Requests ........................................7
3.1. Node Reroute Request .......................................7
3.2. Interface Reroute Request ..................................7
3.3. Component Reroute Request ..................................8
3.4. Label Reroute Request ......................................9
4. IANA Considerations .............................................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
7. Acknowledgments ................................................11
The Resource ReserVation Protocol (RSVP), see [RFC2205], has been extended to support the control of Traffic Engineering (TE) Label Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and [RFC3473]. In all cases, a PathErr message is used to report errors to nodes upstream of the error-detecting node. As defined in [RFC2205] and left unmodified by [RFC3209], PathErr messages "do not change path state in the nodes through which they pass". Notwithstanding this definition, PathErr messages are most commonly used to report errors during LSP establishment, i.e., the RSVP-TE processing that occurs prior to the ingress receiving a Resv message. (See [RFC5711] for a broader discussion on PathErr message handling.) Support for such usage was enhanced via the introduction of the Path_State_Removed flag in [RFC3473], which enables a processing node to free related LSP state and resources. The usage of PathErr messages during LSP establishment was further covered in [RFC4920], which describes in detail how a node may indicate that it or one of its associated resources should be avoided, i.e., routed around, during LSP establishment.
资源预留协议（RSVP）（参见[RFC2205]）已被扩展，以分别支持[RFC3209]和[RFC3473]中多协议标签交换（MPLS）和通用MPLS（GMPLS）的流量工程（TE）标签交换路径（LSP）控制。在所有情况下，PathErr消息都用于向错误检测节点上游的节点报告错误。如[RFC2205]中所定义，且未经[RFC3209]修改，PathErr消息“不会更改它们通过的节点中的路径状态”。尽管有此定义，PathErr消息最常用于在LSP建立期间报告错误，即在入口接收Resv消息之前发生的RSVP-TE处理。（有关PathErr消息处理的更广泛讨论，请参见[RFC5711]）通过在[RFC3473]中引入Path_State_Removed标志增强了对此类使用的支持，该标志使处理节点能够释放相关LSP状态和资源。[RFC4920]中进一步介绍了在LSP建立过程中使用PathErr消息的情况，详细描述了节点如何指示在LSP建立过程中应避免使用它或它的一个相关资源，即绕行路由。
PathErr messages can also be used to support a number of other cases that can occur after an LSP is established. This document focuses on the cases where PathErr messages can be used for a node to indicate that it desires an upstream node to reroute an LSP around the indicating node or resources associated with the indicating node. Some examples of such cases are soft-preemption and graceful shutdown (see [RFC5712] and [GRACEFUL]).
PathErr消息还可用于支持LSP建立后可能发生的许多其他情况。本文档重点介绍PathErr消息可用于节点以指示其希望上游节点围绕指示节点或与指示节点关联的资源重新路由LSP的情况。此类情况的一些示例包括软抢占和正常关机（请参见[RFC5712]和[MANAGETE]）。
This document uses the terminology "reroute request" to refer to the indication by a node that an upstream reroute should take place. This document describes how a node can initiate a reroute request without disrupting LSP data traffic or, when so desired, with the disruption of data traffic and removal of LSP-associated state and resources. The applicability of this document is limited to point-to-point LSPs. Support for point-to-multipoint LSPs are for further study.
本文档使用术语“重路由请求”来表示节点指示应进行上游重路由。本文档描述了节点如何在不中断LSP数据通信的情况下启动重路由请求，或者在需要时，在中断数据通信和删除LSP相关状态和资源的情况下启动重路由请求。本文件的适用范围仅限于点对点LSP。对点对多点LSP的支持有待进一步研究。
The mechanisms used to indicate reroute requests are derived from the mechanisms described in [RFC4920] and the error codes defined in [RFC4736]. This document describes (1) how a non-disruptive reroute request may be issued and, (2) based on an optional "timeout" period, how rerouting may be forced by removing LSP state and associated resources and signaling such removal. While this document describes how existing protocol definitions can be used to support rerouting, it also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values.
用于指示重路由请求的机制源自[RFC4920]中描述的机制和[RFC4736]中定义的错误代码。本文档描述了（1）如何发出无中断重路由请求，以及（2）基于可选的“超时”时间，如何通过移除LSP状态和相关资源并发出移除信号来强制重路由。本文档描述了如何使用现有协议定义来支持重路由，同时还定义了新的重路由特定错误代码，以允许将来定义重路由应用程序特定的错误值。
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 describes how a downstream node can indicate that it desires a node upstream (along the LSP path) to initiate the rerouting of an LSP, and how the upstream nodes can respond to such a request. Initiating nodes, transit nodes, and ingress nodes are described separately.
本节描述下游节点如何指示其希望上游节点（沿着LSP路径）发起LSP的重新路由，以及上游节点如何响应这样的请求。分别描述发起节点、传输节点和入口节点。
When a transit or egress node desires to request the rerouting of an established LSP, it first determines if it can act on the reroute request locally. Such a check MUST be performed on the condition that the Explicit Route Object (ERO), see [RFC3209], received in the LSP's incoming Path message does not preclude LSP rerouting. Examples of requests that may trigger reroutes are avoiding an outgoing interface, a component, label resource, or a next hop not explicitly listed in the ERO. In all cases, the actual repair action SHOULD be performed after verification that the local policy allows local repair for that LSP/state. That is, any traffic-rerouting action (associated to this state) must be initiated and completed only as allowed by local node policy.
当中转或出口节点希望请求已建立LSP的重路由时，它首先确定是否可以在本地对重路由请求采取行动。必须在LSP的传入路径消息中接收的显式路由对象（ERO）（参见[RFC3209]）不排除LSP重新路由的条件下执行此类检查。可能触发重路由的请求示例包括避免ERO中未明确列出的传出接口、组件、标签资源或下一跳。在所有情况下，应在验证本地策略允许对该LSP/状态进行本地修复后执行实际修复操作。也就是说，任何流量重新路由操作（与此状态关联）必须仅在本地节点策略允许的情况下启动和完成。
When the node cannot act locally, it MUST issue a PathErr message indicating its inability to perform local rerouting. The PathErr message MUST contain an ERROR_SPEC object of the format defined in [RFC2205] or [RFC3473]. Such a message MUST include one of the following combinations of error codes and error values:
当节点无法在本地执行操作时，它必须发出PathErr消息，指示其无法执行本地重新路由。PathErr消息必须包含[RFC2205]或[RFC3473]中定义格式的错误规范对象。此类消息必须包括以下错误代码和错误值组合之一：
1. "Notify/Local node maintenance required" to support backwards compatibility and to reroute around the local node.
1. “需要通知/本地节点维护”，以支持向后兼容性并在本地节点周围重新路由。
2. "Notify/Local link maintenance required" to support backwards compatibility and to reroute around a local interface.
2. “需要通知/本地链路维护”，以支持向后兼容性并围绕本地接口重新路由。
3. "Reroute/<any Reroute error value>" for future compatibility and when backwards compatibility is not a concern.
3. “Reroute/<any Reroute error value>”用于将来的兼容性以及不考虑向后兼容性时。
The rest of the ERROR_SPEC object is constructed based on the local rerouting decision and the resource that is to be avoided by an upstream node. It is important to note that the address and TLVs carried by the ERROR_SPEC object identify the resource to be avoided and not the error code and value.
ERROR_SPEC对象的其余部分是基于本地重路由决策和上游节点要避免的资源构建的。需要注意的是，ERROR_SPEC对象携带的地址和TLV标识了要避免的资源，而不是错误代码和值。
When the reroute decision redirects traffic around the local node, the local node MUST be indicated in the ERROR_SPEC object. Otherwise, i.e., when the reroute decision does not redirect traffic around the local node, the impacted interface MUST be indicated in the ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object formats SHOULD be used to indicate the impacted interface.
当重新路由决定重定向本地节点周围的流量时，必须在ERROR_SPEC对象中指示本地节点。否则，即，当重新路由决定不重定向本地节点周围的通信量时，必须在ERROR_SPEC对象中指示受影响的接口，并且应使用IF_ID[RFC3473]ERROR_SPEC对象格式指示受影响的接口。
The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate a reroute request that is more specific than an interface. The TLVs defined in [RFC3471], as updated by [RFC3477], [RFC4201], and [RFC4920] MAY be used to provide specific, additional reroute request information, e.g., reroute around a specific label. The principles related to ERROR_SPEC object construction, defined in Section 6.3.1 of [RFC4920], SHOULD be followed.
IF_ID[RFC3473]ERROR_SPEC对象格式必须用于指示比接口更具体的重路由请求。[RFC3471]中定义的TLV（由[RFC3477]、[RFC4201]和[RFC4920]更新）可用于提供特定的额外重路由请求信息，例如，围绕特定标签重路由。应遵循[RFC4920]第6.3.1节中定义的与错误规格对象构造相关的原则。
Reroute request timeouts are used to remove an LSP when there is no response to a reroute request. A reroute request timeout is used when an LSP is to be removed at the expiration of the reroute request timeout period. When such LSP removal is desired, and after initiating a reroute request, the initiating node MUST initiate a timeout during which it expects to receive a response to the reroute request. Valid responses are a PathTear message or a trigger Path message with an ERO, avoiding the resource that was indicated in the reroute request. If either type of message is received, the timeout period MUST be canceled and no further action is needed. Note, normal refresh processing is not modified by the introduction of reroute request timeouts. Such processing may result in Path state being removed during the timeout period, in which case the timeout period MUST also be canceled.
重路由请求超时用于在对重路由请求没有响应时删除LSP。重新路由请求超时用于在重新路由请求超时期限到期时删除LSP。当需要这样的LSP移除时，并且在发起重路由请求之后，发起节点必须发起超时，在此期间它期望接收对重路由请求的响应。有效的响应是带有ERO的PathTear消息或触发器路径消息，以避免重路由请求中指示的资源。如果收到任何一种类型的消息，则必须取消超时时间，无需采取进一步的操作。注意，正常刷新处理不会因引入重路由请求超时而修改。这种处理可能导致在超时期间删除路径状态，在这种情况下，超时期间也必须取消。
If the reroute request timeout is reached, the initiating node MUST remove the LSP and its associated state and resources. Removal of LSP state is indicated downstream via a corresponding PathTear message. Removal is indicated upstream via a PathErr message with the error code of "Service preempted". The Path_State_Removed flag MUST be set if supported. When the Path_State_Removed flag is not supported, a corresponding ResvTear MUST also be sent.
如果达到重新路由请求超时，则发起节点必须删除LSP及其关联的状态和资源。LSP状态的删除通过相应的PathTear消息在下游指示。删除通过PathErr消息向上游指示，错误代码为“服务抢占”。如果支持，则必须设置路径\状态\移除标志。如果不支持Path_State_Removed标志，则还必须发送相应的ResvTear。
When a transit node's policy permits it to support reroute request processing and local repair, the node MUST examine incoming PathErr messages to see it the node can perform a requested reroute. A reroute request is indicated in a received PathErr message, which carries one of the error code and value combinations listed above in Section 2.1. Note that a conformant implementation MUST check for any of the three combinations listed in Section 2.1.
当传输节点的策略允许其支持重路由请求处理和本地修复时，该节点必须检查传入的PathErr消息，以查看节点是否可以执行请求的重路由。重新路由请求在收到的PathErr消息中指示，该消息携带上述第2.1节中列出的错误代码和值组合之一。注意，一致性实施必须检查第2.1节中列出的三种组合中的任何一种。
A transit node MAY act on a reroute request locally when the ERO received in the LSP's incoming Path message does not preclude the reroute. As before, examples include loosely routed LSP next hops. When the reroute request can be processed locally, standard, local repair processing MUST be followed. The node SHOULD limit the number of local repair attempts. Again, the expected norm is for local repair, and thereby this case, to be precluded due to policy.
当在LSP的传入路径消息中接收到的ERO不排除重路由时，传输节点可以在本地对重路由请求进行操作。如前所述，示例包括松散路由的LSP下一跳。当重新路由请求可以在本地处理时，必须遵循标准的本地修复处理。节点应限制本地修复尝试的次数。同样，预期的标准是局部维修，因此，由于政策原因，这种情况将被排除在外。
When the transit node supports [RFC4920] and is a boundary node, and Boundary rerouting is allowed, it SHOULD use a route request as a trigger to reroute the LSP. (Per [RFC4920], the Flags field of the LSP_ATTRIBUTES object of the initial Path message indicates "Boundary rerouting".) In the case the node triggers rerouting, it first MUST identify an alternate path within the domain. When such a path is available, the node MUST terminate the PathErr message and issue a Path message reflecting the identified alternate path. Processing then continues per [RFC4920]. When an alternate path is not available, the node cannot act on the reroute request.
当中转节点支持[RFC4920]且为边界节点且允许边界重路由时，它应使用路由请求作为重新路由LSP的触发器。（根据[RFC4920]，初始路径消息的LSP_ATTRIBUTES对象的Flags字段指示“边界重路由”。）如果节点触发重路由，它首先必须标识域内的备用路径。当这样的路径可用时，节点必须终止PathErr消息，并发出一条反映已识别备用路径的路径消息。然后根据[RFC4920]继续处理。当备用路径不可用时，节点无法对重路由请求进行操作。
When a transit node cannot act on a reroute request locally, per standard processing, it MUST propagate the received PathErr message to the previous hop.
当传输节点无法按照标准处理在本地对重路由请求进行操作时，它必须将收到的PathErr消息传播到上一个跃点。
When reroute processing is supported, an ingress node MUST check received PathErr messages to identify them as indicating reroute requests. A reroute request is indicated in a received PathErr message, which carries one of the error code and value combinations listed above in Section 2.1. Note that a conformant implementation MUST check for any of the three combinations listed in Section 2.1.
当支持重路由处理时，入口节点必须检查收到的PathErr消息，以将其标识为指示重路由请求。重新路由请求在收到的PathErr消息中指示，该消息携带上述第2.1节中列出的错误代码和值组合之一。注意，一致性实施必须检查第2.1节中列出的三种组合中的任何一种。
Upon receiving a reroute request, the ingress MUST attempt to identify an alternate path, avoiding the node, interface, resource, etc. identified within the ERROR_SPEC object. When an alternate path cannot be identified, the reroute request MUST be discarded. When an
接收到重路由请求后，入口必须尝试识别备用路径，避免错误规范对象中识别的节点、接口、资源等。当无法识别备用路径时，必须放弃重新路由请求。当
alternate path is identified, a corresponding make-before-break LSP SHOULD be initiated and standard make-before-break procedures MUST be followed.
确定备用路径后，应启动相应的先通后断LSP，并且必须遵循标准先通后断程序。
This section provides example reroute requests. This section is informative rather than prescriptive. Reroute requests are always sent via PathErr messages. As described above, a PathErr message may contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID [RFC3473] format ERROR_SPEC object; it is the address and TLVs carried by the ERROR_SPEC object, and not the error value, that indicates the resource that is to be avoided by the reroute.
本节提供了重新路由请求的示例。本节是信息性的，而不是规定性的。重路由请求始终通过PathErr消息发送。如上所述，PathErr消息可能包含[RFC2205]格式错误\u SPEC对象或IF\u ID[RFC3473]格式错误\u SPEC对象；指示重新路由要避免的资源的是ERROR_SPEC对象携带的地址和TLV，而不是ERROR值。
To indicate that the node should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC2205], for example:
为了指示上游节点应避免该节点，发起重路由的节点可根据[RFC2205]格式化错误规范，例如：
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
o IPv4错误\u规范对象：类=6，C类型=1
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local node maintenance required" or "Reroute/<any Reroute error value>".
节点地址设置为本地节点的TE路由器地址。错误代码设置为“需要通知/本地节点维护”或“重新路由/<任何重新路由错误值>”。
To indicate that a numbered interface should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC3473], for example:
为指示上游节点应避免使用编号接口，发起重路由的节点可根据[RFC3473]格式化错误规范，例如：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". IP address is set to the TE address of the interface to be avoided.
节点地址设置为本地节点的TE路由器地址。错误代码设置为“需要通知/本地链路维护”或“重新路由/<任何重新路由错误值>”。IP地址设置为要避免的接口的TE地址。
To indicate that an unnumbered component should be avoided by an upstream node, the node originating the reroute formats the ERROR_SPEC per [RFC4201], for example:
为了指示上游节点应避免未编号的组件，发起重新路由的节点根据[RFC4201]格式化错误规格，例如：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local TE address used in the advertisement of the bundle associated with the component. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". Router ID is set to the local router ID, and Interface ID is the identifier assigned to the component link by the local node.
节点地址设置为本地TE地址，该地址用于发布与组件关联的捆绑包。错误代码设置为“需要通知/本地链路维护”或“重新路由/<任何重新路由错误值>”。路由器ID设置为本地路由器ID，接口ID是本地节点分配给组件链路的标识符。
To indicate that a label should be avoided by an upstream node, the node originating the reroute may format the ERROR_SPEC per [RFC4920], for example:
为了指示上游节点应避免标签，发起重路由的节点可根据[RFC4920]格式化错误规范，例如：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOWNSTREAM_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOWNSTREAM_LABEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error code is set to either "Notify/Local link maintenance required" or "Reroute/<any Reroute error value>". IP address is set to the TE address of the interface that supports the label to be avoided. DOWNSTREAM_LABEL indicates the label to be avoided.
节点地址设置为本地节点的TE路由器地址。错误代码设置为“需要通知/本地链路维护”或“重新路由/<任何重新路由错误值>”。IP地址设置为支持要避免的标签的接口的TE地址。下游标签表示要避免的标签。
IANA assigned values for namespaces defined in this document and reviewed in this section.
IANA为本文档中定义并在本节中回顾的名称空间分配了值。
IANA made the assignment in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP Parameters" registry:
IANA在“RSVP参数”注册表的“错误代码和全局定义的错误值子代码”部分进行分配：
34 Reroute [RFC5710]
34重新路由[RFC5710]
This error code has the following defined Error Value sub-code:
此错误代码具有以下定义的错误值子代码：
0 = Generic LSP reroute request
0 = Generic LSP reroute request
Reroute error values should be allocated based on the following allocation policy as defined in [RFC5226].
应根据[RFC5226]中定义的以下分配策略分配重路由错误值。
Range Registration Procedures
-------- ------------------------
0-32767 IETF Consensus
32768-65535 Private Use
Range Registration Procedures
-------- ------------------------
0-32767 IETF Consensus
32768-65535 Private Use
Sections 9 of [RFC4920] and [RFC4736] should be used as the starting point for reviewing the security considerations related to the formats and mechanisms discussed in this document. This document introduces a new error code, but this code is functionally equivalent to existing semantics, in particular, the error code/error value combinations of "Notify/Local node maintenance required" and "Notify/Local link maintenance required". As such, this document introduces no new security considerations beyond what already applies to these existing formats and mechanisms. Future documents may define new error values; any considerations specific to those values should be discussed in the document defining them. 6. References
[RFC4920]和[RFC4736]的第9节应作为审查与本文件中讨论的格式和机制相关的安全注意事项的起点。本文档引入了一个新的错误代码，但该代码在功能上等同于现有语义，特别是“需要通知/本地节点维护”和“需要通知/本地链接维护”的错误代码/错误值组合。因此，除了已经应用于这些现有格式和机制之外，本文档没有引入任何新的安全注意事项。未来的文档可能会定义新的错误值；应在定义这些值的文档中讨论特定于这些值的任何注意事项。6.工具书类
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化”，RFC 47362006年11月。
[GRACEFUL] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Work in Progress, September 2009.
[优雅]Ali，Z.，Vasseur，JP.，Zamfir，A.，和J.Newton，“MPLS和广义MPLS流量工程网络中的优雅关机”，正在进行的工作，2009年9月。
[RFC5711] Vasseur, JP., Ed., Swallow, G., and I. Minei, "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages", RFC 5711, January 2010.
[RFC5711]Vasseur，JP.，Ed.，Swallow，G.和I.Minei，“发起和接收资源预留协议（RSVP）路径错误消息时的节点行为”，RFC 57112010年1月。
[RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic Engineering Soft Preemption", RFC 5712, January 2010.
[RFC5712]Meyer，M.，Ed.和JP。Vasseur主编，“MPLS流量工程软抢占”，RFC 5712，2010年1月。
This document was conceived along with Matthew Meyer. George Swallow provided valuable feedback. The General Area Review Team (Gen-ART) review was performed by Francis Dupont.
本文件是与Matthew Meyer一起构思的。乔治·斯沃恩提供了宝贵的反馈。一般区域审查小组（Gen ART）的审查由弗朗西斯·杜邦执行。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电话：+1-301-468-9228电子邮件：lberger@labn.net
Dimitri Papadimitriou Alcatel Lucent Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Francis Welleslein 1，B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。Papadimitriou@alcatel-朗讯
JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com
JP Vasseur Cisco Systems，Inc.11，Camille Desmoulins L'Atlantis路92782 Issy Les Moulineaux法国电子邮件：jpv@cisco.com