Network Working Group A. Farrel, Ed.
Request for Comments: 4920 Old Dog Consulting
Category: Standards Track A. Satyanarayana
Cisco Systems, Inc.
A. Iwata
N. Fujita
NEC Corporation
G. Ash
AT&T
July 2007
Network Working Group A. Farrel, Ed.
Request for Comments: 4920 Old Dog Consulting
Category: Standards Track A. Satyanarayana
Cisco Systems, Inc.
A. Iwata
N. Fujita
NEC Corporation
G. Ash
AT&T
July 2007
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
MPLS和GMPLS RSVP-TE的回退信令扩展
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.
在分布式、基于约束的路由环境中，用于计算路径的信息可能已过时。这意味着多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程（TE）标签交换路径（LSP）设置请求可能会被没有足够资源的链路或节点阻止。回退是一种从故障点返回设置失败信息的方案，以允许进行新的设置尝试，从而避免阻塞的资源。回退也可应用于LSP恢复，以指示故障链路或节点的位置。
This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements
本文件规定了在MPLS信令中使用的回退信令扩展，该扩展使用“RSVP-TE：LSP隧道RSVP扩展”RFC 3209中定义的RSVP-TE，以及“通用多协议标签交换（GMPLS）信令功能描述”RFC 3473中定义的GMPLS信令。这些扩展意味着LSP设置请求可以在绕过阻塞链路或节点的备用路径上重试。这提供了显著的改进
in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time.
在LSP的成功安装和恢复率方面，尤其是在同时触发大量安装请求的情况下。
Table of Contents
目录
Section A: Problem Statement
A部分：问题陈述
1. Introduction and Framework ......................................4
1.1. Background .................................................4
1.2. Control Plane and Data Plane Separation ....................5
1.3. Repair and Recovery ........................................5
1.4. Interaction with TE Flooding Mechanisms ....................6
1.5. Terminology ................................................7
2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
3. Required Operation ..............................................8
3.1. Resource Failure or Unavailability .........................8
3.2. Computation of an Alternate Path ...........................8
3.2.1. Information Required for Re-Routing .................9
3.2.2. Signaling a New Route ...............................9
3.3. Persistence of Error Information ..........................10
3.4. Handling Re-Route Failure .................................11
3.5. Limiting Re-Routing Attempts ..............................11
4. Existing Protocol Support for Crankback Re-Routing .............11
4.1. RSVP-TE ...................................................12
4.2. GMPLS-RSVP-TE .............................................13
1. Introduction and Framework ......................................4
1.1. Background .................................................4
1.2. Control Plane and Data Plane Separation ....................5
1.3. Repair and Recovery ........................................5
1.4. Interaction with TE Flooding Mechanisms ....................6
1.5. Terminology ................................................7
2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
3. Required Operation ..............................................8
3.1. Resource Failure or Unavailability .........................8
3.2. Computation of an Alternate Path ...........................8
3.2.1. Information Required for Re-Routing .................9
3.2.2. Signaling a New Route ...............................9
3.3. Persistence of Error Information ..........................10
3.4. Handling Re-Route Failure .................................11
3.5. Limiting Re-Routing Attempts ..............................11
4. Existing Protocol Support for Crankback Re-Routing .............11
4.1. RSVP-TE ...................................................12
4.2. GMPLS-RSVP-TE .............................................13
Section B: Solution
B节：解决办法
5. Control of Crankback Operation .................................13
5.1. Requesting Crankback and Controlling In-Network
Re-Routing ................................................13
5.2. Action on Detecting a Failure .............................14
5.3. Limiting Re-Routing Attempts ..............................14
5.3.1. New Status Codes for Re-Routing ....................15
5.4. Protocol Control of Re-Routing Behavior ...................15
6. Reporting Crankback Information ................................15
6.1. Required Information ......................................15
6.2. Protocol Extensions .......................................16
6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
6.3.1. General Principles .................................20
6.3.2. Error Report TLVs ..................................21
6.3.3. Fundamental Crankback TLVs .........................21
6.3.4. Additional Crankback TLVs ..........................22
6.3.5. Grouping TLVs by Failure Location ..................23
6.3.6. Alternate Path Identification ......................24
6.4. Action on Receiving Crankback Information .................25
6.4.1. Re-Route Attempts ..................................25
5. Control of Crankback Operation .................................13
5.1. Requesting Crankback and Controlling In-Network
Re-Routing ................................................13
5.2. Action on Detecting a Failure .............................14
5.3. Limiting Re-Routing Attempts ..............................14
5.3.1. New Status Codes for Re-Routing ....................15
5.4. Protocol Control of Re-Routing Behavior ...................15
6. Reporting Crankback Information ................................15
6.1. Required Information ......................................15
6.2. Protocol Extensions .......................................16
6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
6.3.1. General Principles .................................20
6.3.2. Error Report TLVs ..................................21
6.3.3. Fundamental Crankback TLVs .........................21
6.3.4. Additional Crankback TLVs ..........................22
6.3.5. Grouping TLVs by Failure Location ..................23
6.3.6. Alternate Path Identification ......................24
6.4. Action on Receiving Crankback Information .................25
6.4.1. Re-Route Attempts ..................................25
6.4.2. Location Identifiers of Blocked Links or Nodes .....25
6.4.3. Locating Errors within Loose or Abstract Nodes .....26
6.4.4. When Re-Routing Fails ..............................26
6.4.5. Aggregation of Crankback Information ...............26
6.5. Notification of Errors ....................................27
6.5.1. ResvErr Processing .................................27
6.5.2. Notify Message Processing ..........................28
6.6. Error Values ..............................................28
6.7. Backward Compatibility ....................................28
7. LSP Recovery Considerations ....................................29
7.1. Upstream of the Fault .....................................29
7.2. Downstream of the Fault ...................................30
8. IANA Considerations ............................................30
8.1. Error Codes ...............................................30
8.2. IF_ID_ERROR_SPEC TLVs .....................................31
8.3. LSP_ATTRIBUTES Object .....................................31
9. Security Considerations ........................................31
10. Acknowledgments ...............................................32
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................33
Appendix A.........................................................35
6.4.2. Location Identifiers of Blocked Links or Nodes .....25
6.4.3. Locating Errors within Loose or Abstract Nodes .....26
6.4.4. When Re-Routing Fails ..............................26
6.4.5. Aggregation of Crankback Information ...............26
6.5. Notification of Errors ....................................27
6.5.1. ResvErr Processing .................................27
6.5.2. Notify Message Processing ..........................28
6.6. Error Values ..............................................28
6.7. Backward Compatibility ....................................28
7. LSP Recovery Considerations ....................................29
7.1. Upstream of the Fault .....................................29
7.2. Downstream of the Fault ...................................30
8. IANA Considerations ............................................30
8.1. Error Codes ...............................................30
8.2. IF_ID_ERROR_SPEC TLVs .....................................31
8.3. LSP_ATTRIBUTES Object .....................................31
9. Security Considerations ........................................31
10. Acknowledgments ...............................................32
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................33
Appendix A.........................................................35
Section A : Problem Statement
A部分：问题陈述
RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for establishing explicitly routed LSPs in an MPLS network. Using RSVP-TE, resources can also be reserved along a path to guarantee and/or control QoS for traffic carried on the LSP. To designate an explicit path that satisfies Quality of Service (QoS) guarantees, it is necessary to discern the resources available to each link or node in the network. For the collection of such resource information, routing protocols, such as OSPF and Intermediate System to Intermediate System (IS-IS), can be extended to distribute additional state information [RFC2702].
RSVP-TE（LSP隧道的RSVP扩展）[RFC3209]可用于在MPLS网络中建立显式路由LSP。使用RSVP-TE，还可以沿路径保留资源，以保证和/或控制LSP上承载的业务的QoS。要指定满足服务质量（QoS）保证的显式路径，必须识别网络中每个链路或节点可用的资源。为了收集此类资源信息，可以扩展路由协议，如OSPF和中间系统到中间系统（IS-IS），以分发额外的状态信息[RFC2702]。
Explicit paths can be computed based on the distributed information at the LSR (ingress) initiating an LSP and signaled as Explicit Routes during LSP establishment. Explicit Routes may contain 'loose hops' and 'abstract nodes' that convey routing through a collection of nodes. This mechanism may be used to devolve parts of the path computation to intermediate nodes such as area border LSRs.
显式路径可以基于发起LSP的LSR（入口）处的分布式信息来计算，并在LSP建立期间作为显式路由发信号。显式路由可能包含通过节点集合传递路由的“松散跃点”和“抽象节点”。该机制可用于将部分路径计算转移到中间节点，如区域边界LSR。
In a distributed routing environment, however, the resource information used to compute a constraint-based path may be out of date. This means that a setup request may be blocked, for example, because a link or node along the selected path has insufficient resources.
然而，在分布式路由环境中，用于计算基于约束的路径的资源信息可能已经过时。这意味着设置请求可能会被阻止，例如，因为沿所选路径的链接或节点没有足够的资源。
In RSVP-TE, a blocked LSP setup may result in a PathErr message sent to the ingress, or a ResvErr sent to the egress (terminator). These messages may result in the LSP setup being abandoned. In Generalized MPLS [RFC3473] the Notify message may additionally be used to expedite notification of failures of existing LSPs to ingress and egress LSRs, or to a specific "repair point" -- an LSR responsible for performing protection or restoration.
在RSVP-TE中，被阻止的LSP设置可能导致发送到入口的PathErr消息，或发送到出口（终止器）的ResvErr消息。这些消息可能导致LSP设置被放弃。在通用MPLS[RFC3473]中，通知消息还可用于加速向入口和出口LSR或特定“修复点”——负责执行保护或恢复的LSR——通知现有LSP的故障。
These existing mechanisms provide a certain amount of information about the path of the failed LSP.
这些现有机制提供了有关失败LSP路径的一定数量的信息。
Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks that manage Layer 2, TDM and lambda resources as well as packet resources. Thus, crankback routing is also useful in GMPLS networks.
广义MPLS[RFC3471]和[RFC3473]将MPLS扩展到管理第2层、TDM和lambda资源以及数据包资源的网络中。因此，回溯路由在GMPLS网络中也很有用。
In a network without wavelength converters, setup requests are likely to be blocked more often than in a conventional MPLS environment because the same wavelength must be allocated at each Optical Cross-
在没有波长转换器的网络中，由于必须在每个光交叉处分配相同的波长，因此设置请求可能比传统MPLS环境中更经常地被阻止-
Connect on an end-to-end explicit path. This makes crankback routing all the more important in certain GMPLS networks.
在端到端显式路径上连接。这使得回溯路由在某些GMPLS网络中变得更加重要。
Throughout this document, the processes and techniques are described as though the control plane and data plane elements that comprise a Label Switching Router (LSR) coreside and are related in a one-to-one manner. This is for the convenience of documentation only.
在本文档中，过程和技术被描述为包括标签交换路由器（LSR）核心侧的控制平面和数据平面元素，并且以一对一的方式相互关联。这只是为了便于文档编制。
It should be noted that GMPLS LSRs may be decomposed such that the control plane components are not physically collocated. Furthermore, one presence in the control plane may control more than one LSR in the data plane. These points have several consequences with respect to this document:
应注意，GMPLS LSR可被分解，以使控制平面组件不在物理上并置。此外，控制平面中的一个存在可以控制数据平面中的多个LSR。这些要点对本文件有几个影响：
o The nodes, links, and resources that are reported as errors, are data plane entities.
o 报告为错误的节点、链接和资源是数据平面实体。
o The nodes, areas, and Autonomous Systems (ASs) that report that they have attempted re-routing are control plane entities.
o 报告已尝试重新路由的节点、区域和自治系统（ASs）是控制平面实体。
o Where a single control plane entity is responsible for more than one data plane LSR, crankback signaling may be implicit in just the same way as LSP establishment signaling may be.
o 在单个控制平面实体负责多个数据平面LSR的情况下，回退信令可以以与LSP建立信令相同的方式隐含。
The above points may be considered self-evident, but are stated here for absolute clarity.
以上几点可能被认为是不言而喻的，但为了绝对清楚起见，在此予以说明。
The stylistic convenience of referring to both the control plane element responsible for a single LSR and the data plane component of that LSR simply as "the LSR" should not be taken to mean that this document is applicable only to a collocated one-to-one relationship. Furthermore, in the majority of cases, the control plane and data plane components are related in a 1:1 ratio and are usually collocated.
将负责单个LSR的控制平面元素和该LSR的数据平面组件简单地称为“LSR”在文体上的便利性不应被视为本文件仅适用于并置的一对一关系。此外，在大多数情况下，控制平面和数据平面组件以1:1的比例关联，并且通常并置。
If the ingress LSR or intermediate area border LSR knows the location of the blocked link or node, it can designate an alternate path and then reissue the setup request. Determination of the identity of the blocked link or node can be achieved by the mechanism known as crankback routing [PNNI, ASH1]. In RSVP-TE, crankback signaling requires notifying the upstream LSR of the location of the blocked link or node. In some cases, this requires more information than is currently available in the signaling protocols.
如果入口LSR或中间区域边界LSR知道阻塞链路或节点的位置，则可以指定备用路径，然后重新发出设置请求。可通过称为回退路由的机制[PNNI，ASH1]来确定阻塞链路或节点的身份。在RSVP-TE中，回退信令要求将阻塞链路或节点的位置通知上游LSR。在某些情况下，这需要比当前信令协议中可用的更多的信息。
On the other hand, various recovery schemes for link or node failures have been proposed in [RFC3469] and include fast re-routing. These schemes rely on the existence of a protecting LSP to protect the working LSP, but if both the working and protecting paths fail, it is necessary to re-establish the LSP on an end-to-end basis, avoiding the known failures. Similarly, fast re-routing by establishing a recovery path on demand after failure requires computation of a new LSP that avoids the known failures. End-to-end recovery for alternate routing requires the location of the failed link or node. Crankback routing schemes could be used to notify the upstream LSRs of the location of the failure.
另一方面，[RFC3469]中提出了各种链路或节点故障恢复方案，包括快速重路由。这些方案依赖于保护LSP的存在来保护工作LSP，但是如果工作路径和保护路径都失败，则有必要在端到端的基础上重新建立LSP，以避免已知的失败。类似地，通过在故障后按需建立恢复路径来快速重新路由需要计算新的LSP，以避免已知故障。备用路由的端到端恢复需要故障链路或节点的位置。回退路由方案可用于通知上游LSR故障位置。
Furthermore, in situations where many link or node failures occur at the same time, the difference between the distributed routing information and the real-time network state becomes much greater than in normal LSP setups. LSP recovery might, therefore, be performed with inaccurate information, which is likely to cause setup blocking. Crankback routing could improve failure recovery in these situations.
此外，在同时发生多个链路或节点故障的情况下，分布式路由信息和实时网络状态之间的差异比正常LSP设置中的差异大得多。因此，LSP恢复可能在信息不准确的情况下执行，这可能会导致安装程序阻塞。在这些情况下，回退路由可以改进故障恢复。
The requirement for end-to-end allocation of lambda resources in GMPLS networks without wavelength converters means that end-to-end recovery may be the only way to recover from LSP failures. This is because segment protection may be much harder to achieve in networks of photonic cross-connects where a particular lambda may already be in use on other links: End-to-end protection offers the choice of use of another lambda, but this choice is not available in segment protection.
在没有波长转换器的GMPLS网络中，端到端分配lambda资源的要求意味着端到端恢复可能是从LSP故障中恢复的唯一方法。这是因为在光子交叉连接的网络中，段保护可能更难实现，其中一个特定的lambda可能已经在其他链路上使用：端到端保护提供了另一个lambda的使用选择，但在段保护中，此选择不可用。
This requirement makes crankback re-routing particularly useful in a GMPLS network, particularly in dynamic LSP re-routing cases (i.e., when there is no pre-establishment of the protecting LSP).
这一要求使得回溯重路由在GMPLS网络中特别有用，特别是在动态LSP重路由情况下（即，当没有预先建立保护LSP时）。
GMPLS uses Interior Gateway Protocols (IGPs) (OSPF and IS-IS) to flood traffic engineering (TE) information that is used to construct a traffic engineering database (TED) which acts as a data source for path computation.
GMPLS使用内部网关协议（IGPs）（OSPF和IS-IS）来传播流量工程（TE）信息，该信息用于构建流量工程数据库（TED），作为路径计算的数据源。
Crankback signaling is not intended to supplement or replace the normal operation of the TE flooding mechanism, since these mechanisms are independent of each other. That is, information gathered from crankback signaling may be applied to compute an alternate path for the LSP for which the information was signaled, but the information is not intended to be used to influence the computation of the paths of other LSPs.
由于TE溢流机构相互独立，因此回转信号不用于补充或替代TE溢流机构的正常运行。也就是说，从回退信令收集的信息可被应用于计算发送了该信息的LSP的备用路径，但是该信息并不打算被用于影响其他LSP的路径的计算。
Any requirement to rapidly flood updates about resource availability so that they may be applied as deltas to the TED and utilized in future path computations are out of the scope of this document.
任何关于快速更新资源可用性的要求，以便将其作为增量应用于TED，并在未来的路径计算中使用，都不在本文件的范围内。
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]中所述进行解释。
There have been problems in service provider networks when "inferring" from indirect information that re-routing is allowed. This document proposes the use of an explicit re-routing indication that authorizes re-routing, and contrasts it with the inferred or implicit re-routing indication that has previously been used.
在服务提供商网络中，当从间接信息“推断”允许重新路由时，出现了一些问题。本文件建议使用明确的重新布线指示来授权重新布线，并将其与先前使用的推断或隐含的重新布线指示进行对比。
Various existing protocol options and exchanges, including the error values of PathErr message [RFC2205, RFC3209] and the Notify message [RFC3473], allow an implementation to infer a situation where re-routing can be performed. This allows for recovery from network errors or resource contention.
各种现有协议选项和交换，包括PathErr消息[RFC2205，RFC3209]和Notify消息[RFC3473]的错误值，允许实现推断可以执行重新路由的情况。这允许从网络错误或资源争用中恢复。
However, such inference of recovery signaling is not always desirable since it may be doomed to failure. For example, experience of using release messages in TDM-based networks, for analogous implicit and explicit re-routing indications purposes provides some guidance. This background information is given in Appendix A.
然而，恢复信令的这种推断并不总是可取的，因为它可能注定失败。例如，在基于TDM的网络中为类似的隐式和显式重路由指示目的使用释放消息的经验提供了一些指导。本背景资料见附录A。
It is certainly the case that with topology information distribution, as performed with routing protocols such as OSPF, the ingress LSR could infer the re-routing condition. However, convergence of topology information using routing protocols is typically slower than the expected LSP setup times. One of the reasons for crankback is to avoid the overhead of available-link-bandwidth flooding, and to more efficiently use local state information to direct alternate routing to the path computation point.
当然，在拓扑信息分布的情况下，如使用OSPF等路由协议所执行的，入口LSR可以推断重新路由条件。然而，使用路由协议聚合拓扑信息通常比预期的LSP设置时间慢。回退的原因之一是避免可用链路带宽泛滥的开销，并更有效地使用本地状态信息将备用路由定向到路径计算点。
[ASH1] shows how event-dependent-routing can just use crankback, and not available-link-bandwidth flooding, to decide on the re-route path in the network through "learning models". Reducing this flooding reduces overhead and can lead to the ability to support much larger AS sizes.
[ASH1]展示了事件相关路由如何通过“学习模型”使用回退和不可用链路带宽泛洪来决定网络中的重新路由路径。减少这种泛洪会减少开销，并能够支持更大的AS大小。
Therefore, the use of alternate routing should be based on an explicit indication, and it is best to know the following information separately:
因此，备用路由的使用应基于明确指示，最好单独了解以下信息：
- where blockage/congestion occurred.
- 发生堵塞/堵塞的地方。
- whether alternate routing "should" be attempted.
- 是否尝试替代路由“应”。
Section 1 identifies some of the circumstances under which crankback may be useful. Crankback routing is performed as described in the following procedures, when an LSP setup request is blocked along the path or when an existing LSP fails.
第1节确定了一些可能有用的回退情况。当LSP设置请求沿路径受阻或现有LSP失败时，将按照以下步骤中所述执行回退路由。
When an LSP setup request is blocked due to unavailable resources, an error message response with the location identifier of the blockage should be returned to the LSR initiating the LSP setup (ingress LSR), the area border LSR, the AS border LSR, or some other repair point.
当LSP设置请求因资源不可用而被阻止时，带有阻塞位置标识符的错误消息响应应返回给启动LSP设置（入口LSR）、区域边界LSR、AS边界LSR或某些其他修复点的LSR。
This error message carries an error specification according to [RFC3209] -- this indicates the cause of the error and the node/link on which the error occurred. Crankback operation may require further information as detailed in Sections 3.2.1 and 6.
此错误消息根据[RFC3209]携带错误规范——这表示错误的原因以及发生错误的节点/链路。如第3.2.1节和第6节所述，曲轴回转操作可能需要更多信息。
A repair point (for example, an ingress LSR) that receives crankback information resulting from the failure of an established LSP may apply local policy to govern how it attempts repair of the LSP. For example, it may prioritize repair attempts between multiple LSPs that have failed, and it may consider LSPs that have been locally repaired ([RFC4090]) to be less urgent candidates for end-to-end repair. Furthermore, there is a likelihood that other LSRs are also attempting LSP repair for LSPs affected by the same fault which may give rise to resource contention within the network, so an LSR may stagger its repair attempts in order to reduce the chance of resource contention.
接收由已建立的LSP故障导致的回退信息的修复点（例如，入口LSR）可以应用本地策略来控制其尝试修复LSP的方式。例如，它可以区分已经失败的多个LSP之间的修复尝试，并且可以考虑已经在本地修复的LSP（[RCF4090]）是用于端到端修复的较不紧急的候选。此外，有可能其他LSR也在尝试对受相同故障影响的LSP进行LSP修复，这可能导致网络内的资源争用，因此LSR可以错开其修复尝试以减少资源争用的机会。
In a flat network without partitioning of the routing topology, when the ingress LSR receives the error message, it computes an alternate path around the blocked link or node to satisfy QoS guarantees using link state information about the network. If an alternate path is found, a new LSP setup request is sent over this path.
在没有划分路由拓扑的平面网络中，当入口LSR接收到错误消息时，它使用有关网络的链路状态信息计算阻塞链路或节点周围的备用路径以满足QoS保证。如果找到备用路径，将通过该路径发送新的LSP设置请求。
On the other hand, in a network partitioned into areas such as with OSPF, the area border LSR may intercept and terminate the error response, and perform alternate (re-)routing within the downstream area.
另一方面，在诸如用OSPF划分成区域的网络中，区域边界LSR可以截获并终止错误响应，并在下游区域内执行备用（重新）路由。
In a third scenario, any node within an area may act as a repair point. In this case, each LSR behaves much like an area border LSR as described above. It can intercept and terminate the error response and perform alternate routing. This may be particularly useful where domains of computation are applied within the (partitioned) network, where such domains are not coincident on the routing partition boundaries. However if, all nodes in the network perform re-routing it is possible to spend excessive network and CPU resources on re-routing attempts that would be better made only at designated re-routing nodes. This scenario is somewhat like 'MPLS fast re-route' [RFC4090], in which any node in the MPLS domain can establish 'local repair' LSPs upon failure notification.
在第三种情况下，区域内的任何节点都可以充当修复点。在这种情况下，每个LSR的行为非常类似于如上所述的区域边界LSR。它可以拦截和终止错误响应，并执行备用路由。当计算域应用于（分区的）网络内时，这可能特别有用，其中这些域在路由分区边界上不重合。但是，如果网络中的所有节点都执行重路由，则可能会在重路由尝试上花费过多的网络和CPU资源，而这种尝试最好只在指定的重路由节点上进行。此场景有点像“MPLS快速重路由”[RFC4090]，其中MPLS域中的任何节点都可以在收到故障通知时建立“本地修复”LSP。
In order to correctly compute a route that avoids the blocking problem, a repair point LSR must gather as much crankback information as possible. Ideally, the repair node will be given the node, link, and reason for the failure.
为了正确计算避免阻塞问题的路线，维修点LSR必须收集尽可能多的回退信息。理想情况下，修复节点将获得节点、链接和故障原因。
The reason for the failure may provide an important discriminator to help decide what action should be taken. For example, a failure that indicates "No Route to Destination" is likely to give rise to a new path computation excluding the reporting LSR, but the reason "Temporary Control Plane Congestion" might lead to a simple retry after a suitable pause.
失败的原因可能会提供一个重要的判别因素，帮助决定应该采取什么行动。例如，指示“没有到目的地的路由”的故障可能会导致新的路径计算（不包括报告的LSR），但“临时控制平面拥塞”的原因可能会导致在适当的暂停后进行简单的重试。
However, even this information may not be enough to help with re-computation. Consider for instance an explicit route that contains a non-explicit abstract node or a loose hop. In this case, the failed node and link are not necessarily enough to tell the repair point which hop in the explicit route has failed. The crankback information needs to indicate where, within the explicit route, the problem has occurred.
然而，即使这些信息也不足以帮助重新计算。例如，考虑包含非显式抽象节点或松散跳跃的显式路由。在这种情况下，发生故障的节点和链路不一定足以告诉修复点显式路由中的哪个跃点发生故障。回退信息需要指示在显式路由中问题发生的位置。
If the crankback information can be used to compute a new route avoiding the failed/blocking network resource, the route can be signaled as an Explicit Route.
如果回退信息可用于计算避免故障/阻塞网络资源的新路由，则该路由可作为显式路由发出信号。
However, it may be that the repair point does not have sufficient topology information to compute an Explicit Route that is guaranteed to avoid the failed link or node. In this case, Route Exclusions [RFC4874] may be particularly helpful. To achieve this, [RFC4874] allows the crankback information to be presented as route exclusions to force avoidance of the failed node, link, or resource.
然而，可能是修复点没有足够的拓扑信息来计算保证避免故障链路或节点的显式路由。在这种情况下，路由排除[RFC4874]可能特别有用。为了实现这一点，[RFC4874]允许将回退信息显示为路由排除，以强制避免出现故障的节点、链路或资源。
The repair point LSR that computes the alternate path should store the location identifiers of the blockages indicated in the error message until the LSP is successfully established by downstream LSRs or until the repair point LSR abandons re-routing attempts. Since crankback signaling information may be returned to the same repair point LSR more than once while establishing a specific LSP, the repair point LSR SHOULD maintain a history table of all experienced blockages for this LSP (at least until the routing protocol updates the state of this information) so that the resulting path computation(s) can detour all blockages.
计算备用路径的修复点LSR应存储错误消息中指示的阻塞的位置标识符，直到下游LSR成功建立LSP或直到修复点LSR放弃重新路由尝试。由于在建立特定LSP时，回退信令信息可以多次返回到同一修复点LSR，因此修复点LSR应该维护该LSP的所有经历过的阻塞的历史表（至少在路由协议更新该信息的状态之前），以便得到的路径计算可以绕过所有的障碍。
If a second error response is received by a repair point (while it is performing crankback re-routing) it should update the history table that lists all experienced blockages, and use the entire gathered information when making a further re-routing attempt.
如果维修点接收到第二个错误响应（在执行回退重路由时），则应更新列出所有经历过的阻塞的历史记录表，并在进行进一步重路由尝试时使用收集的全部信息。
Note that the purpose of this history table is to correlate information when repeated retry attempts are made by the same LSR. For example, suppose that an attempt is made to route from A through B, and B returns a failure with crankback information, an attempt may be made to route from A through C, and this may also fail with the return of crankback information. The next attempt SHOULD NOT be to route from A through B, and this may be achieved by use of the history table.
请注意，此历史记录表的目的是在同一LSR重复重试时关联信息。例如，假设尝试从A路由到B，B返回故障并返回回退信息，则可能尝试从A路由到C，也可能返回回退信息而失败。下一次尝试不应该是从A路由到B，这可以通过使用历史表来实现。
The history table can be discarded by the signaling controller for A if the LSP is successfully established through A. The history table MAY be retained after the signaling controller for A sends an error upstream, however the value this provides is questionable since a future retry as a result of crankback re-routing should not attempt to route through A. If the history information is retained for a longer period it SHOULD be discarded after a local timeout has expired. This timer is required so that the repair point does not apply the history table to an attempt by the ingress to re-establish a failed LSP, but to allow the history table to be available for use in re-routing attempts before the ingress declares the LSP as failed.
如果通过A成功建立LSP，A的信令控制器可以丢弃历史表。A的信令控制器向上游发送错误后，可以保留历史表，但是，这提供的值值得怀疑，因为由于回退重新路由而导致的未来重试不应尝试通过路由。如果历史信息保留较长时间，则应在本地超时过期后丢弃。需要此计时器，以便修复点不会将历史表应用于入口尝试重新建立失败的LSP，而是允许历史表在入口声明LSP失败之前用于重新路由尝试。
It is RECOMMENDED that the repair point LSR discard the history table using a timer no larger than the LSP retry timer configured on the ingress LSR. The correlation of the timers between the ingress and repair point LSRs is typically by manual configuration of timers local to each LSR, and is outside the scope of this document.
建议修复点LSR使用不大于入口LSR上配置的LSP重试计时器的计时器丢弃历史记录表。入口和维修点LSR之间的计时器相关性通常通过手动配置每个LSR的本地计时器来实现，不在本文档的范围内。
The information in the history table is not intended to supplement the TED for the computation of paths of other LSPs.
历史记录表中的信息并非用于补充TED，以计算其他LSP的路径。
Multiple blockages (for the same LSP) may occur, and successive setup retry attempts may fail. Retaining error information from previous attempts ensures that there is no thrashing of setup attempts, and knowledge of the blockages increases with each attempt.
可能会发生多个阻塞（对于同一LSP），连续的安装重试尝试可能会失败。保留以前尝试中的错误信息可确保安装尝试不会出现颠簸，每次尝试都会增加对阻塞的了解。
It may be that after several retries, a given repair point is unable to compute a path to the destination (that is, the egress of the LSP) that avoids all of the blockages. In this case, it must pass an error indication message upstream. It is most useful to the upstream nodes (and in particular to the ingress LSR) that may repair points for the LSP setup, if the error indication message identifies all of the downstream blockages and also the repair point that was unable to compute an alternate path.
可能是在多次重试之后，给定的修复点无法计算到目的地的路径（即，LSP的出口），从而避免所有阻塞。在这种情况下，它必须向上游传递错误指示消息。如果错误指示消息识别了所有下游阻塞以及无法计算备用路径的修复点，则它对可能修复LSP设置点的上游节点（尤其是入口LSR）最有用。
It is important to prevent endless repetition of LSP setup attempts using crankback routing information after error conditions are signaled, or during periods of high congestion. It may also be useful to reduce the number of retries, since failed retries will increase setup latency and degrade performance by increasing the amount of signaling processing and message exchanges within the network.
在错误条件发出信号后或在高拥塞期间，使用回退路由信息防止LSP设置尝试无休止地重复非常重要。减少重试次数也很有用，因为失败的重试会增加网络内的信令处理和消息交换量，从而增加设置延迟并降低性能。
The maximum number of crankback re-routing attempts that are allowed may be limited in a variety of ways. This document allows an LSR to limit the retries per LSP, and assumes that such a limit will be applied either as a per-node configuration for those LSRs that are capable of re-routing, or as a network-wide configuration value.
允许的回退重新路由尝试的最大次数可能会受到多种方式的限制。本文档允许LSR限制每个LSP的重试次数，并假设此限制将作为能够重新路由的LSR的每个节点配置，或作为网络范围的配置值应用。
When the number of retries at a particular LSR is exceeded, the LSR will report the failure in an upstream direction until it reaches the next repair point where further re-routing attempts may be attempted, or it reaches the ingress which may act as a repair point or declare the LSP as failed. It is important that the crankback information this is provided indicates that routing back through this node will not succeed; this situation is similar to that in Section 3.4.
当超过特定LSR的重试次数时，LSR将向上游方向报告故障，直到到达下一个修复点，在该修复点上可能会尝试进一步的重新路由尝试，或者到达可能作为修复点或宣布LSP失败的入口。重要的是，所提供的回退信息表明通过该节点的回退路由将不会成功；这种情况与第3.4节中的情况类似。
Crankback re-routing is appropriate for use with RSVP-TE.
回退重新布线适用于RSVP-TE。
1) LSP establishment may fail because of an inability to route, perhaps because links are down. In this case a PathErr message is returned to the ingress.
1) LSP建立可能会因为无法路由而失败，可能是因为链路中断。在这种情况下，将向入口返回一条PathErr消息。
2) LSP establishment may fail because resources are unavailable. This is particularly relevant in GMPLS where explicit label control may be in use. Again, a PathErr message is returned to the ingress.
2) 由于资源不可用，LSP建立可能失败。这在可能使用显式标签控制的GMPLS中尤其相关。同样，PathErr消息返回到入口。
3) Resource reservation may fail during LSP establishment, as the Resv is processed. If resources are not available on the required link or at a specific node, a ResvErr message is returned to the egress node indicating "Admission Control failure" [RFC2205]. The egress is allowed to change the FLOWSPEC and try again, but in the event that this is not practical or not supported (particularly in the non-PSC context), the egress LSR may choose to take any one of the following actions.
3) 在LSP建立过程中，随着Resv的处理，资源保留可能会失败。如果所需链路或特定节点上的资源不可用，则向出口节点返回ResvErr消息，指示“准入控制失败”[RFC2205]。允许出口更改FLOWSPEC并重试，但如果这不可行或不受支持（特别是在非PSC上下文中），出口LSR可以选择采取以下任一操作。
- Ignore the situation and allow recovery to happen through Path refresh message and refresh timeout [RFC2205].
- 忽略该情况，并允许通过路径刷新消息和刷新超时[RFC2205]进行恢复。
- Send a PathErr message towards the ingress indicating "Admission Control failure".
- 向入口发送PathErr消息，指示“准入控制失败”。
Note that in multi-area/AS networks, the ResvErr might be intercepted and acted on at an area/AS border router.
请注意，在多区域/AS网络中，ResvErr可能会被拦截并在区域/AS边界路由器上执行操作。
4) It is also possible to make resource reservations on the forward path as the Path message is processed. This choice is compatible with LSP setup in GMPLS networks [RFC3471], [RFC3473]. In this case, if resources are not available, a PathErr message is returned to ingress indicating "Admission Control failure".
4) 在处理路径消息时，还可以在转发路径上保留资源。此选项与GMPLS网络[RFC3471]、[RFC3473]中的LSP设置兼容。在这种情况下，如果资源不可用，将向入口返回一条PathErr消息，指示“准入控制失败”。
Crankback information would be useful to an upstream node (such as the ingress) if it is supplied on a PathErr or a Notify message that is sent upstream.
如果在PathErr或向上游发送的Notify消息中提供回溯信息，则回溯信息对上游节点（如入口）非常有用。
In RSVP-TE, a failed LSP setup attempt results in a PathErr message returned upstream. The PathErr message carries an ERROR_SPEC object, which indicates the node or interface reporting the error and the reason for the failure.
在RSVP-TE中，LSP设置尝试失败会导致向上游返回PathErr消息。PathErr消息包含一个ERROR_SPEC对象，它指示报告错误的节点或接口以及失败的原因。
Crankback re-routing can be performed explicitly avoiding the node or interface reported.
可以显式执行回退重新路由，避免报告的节点或接口。
GMPLS extends the error reporting described above by allowing LSRs to report the interface that is in error in addition to the identity of the node reporting the error. This further enhances the ability of a re-computing node to route around the error.
GMPLS通过允许LSR除了报告错误的节点的标识之外，还报告出错的接口，扩展了上述错误报告。这进一步增强了重新计算节点绕过错误路由的能力。
GMPLS introduces a targeted Notify message that may be used to report LSP failures direct to a selected node. This message carries the same error reporting facilities as described above. The Notify message may be used to expedite the propagation of error notifications, but in a network that offers crankback routing at multiple nodes there would need to be some agreement between LSRs as to whether PathErr or Notify provides the stimulus for crankback operation. This agreement is constrained by the re-routing behavior selection (as listed in Section 5.4). Otherwise, multiple nodes might attempt to repair the LSP at the same time, because:
GMPLS引入了一个目标通知消息，可用于直接向所选节点报告LSP故障。此消息具有与上述相同的错误报告功能。Notify消息可用于加快错误通知的传播，但在多个节点上提供回退路由的网络中，LSR之间需要就PathErr或Notify是否提供回退操作刺激达成一致。本协议受重新布线行为选择的约束（如第5.4节所列）。因为多个LSP可能会同时尝试修复：
1) these messages can flow through different paths before reaching the ingress LSR, and
1) 这些消息可以在到达入口LSR之前通过不同的路径，并且
2) the destination of the Notify message might not be the ingress LSR.
2) Notify消息的目标可能不是入口LSR。
Section B : Solution
B节：解决办法
When a request is made to set up an LSP tunnel, the ingress LSR should specify whether it wants crankback information to be collected in the event of a failure, and whether it requests re-routing attempts by any or specific intermediate nodes. For this purpose, a Re-routing Flag field is added to the protocol setup request messages. The corresponding values are mutually exclusive.
当请求设置LSP隧道时，入口LSR应指定是否希望在发生故障时收集回退信息，以及是否请求任何或特定中间节点的重新路由尝试。为此，在协议设置请求消息中添加了重新路由标志字段。相应的值是互斥的。
No Re-routing The ingress node MAY attempt re-routing after failure. Intermediate nodes SHOULD NOT attempt re-routing after failure. Nodes detecting failures MUST report an error and MAY supply crankback information. This is the default and backwards compatible option.
无重新路由入口节点可在故障后尝试重新路由。中间节点不应在故障后尝试重新路由。检测故障的节点必须报告错误，并可能提供回退信息。这是默认的向后兼容选项。
End-to-end Re-routing The ingress node MAY attempt re-routing after failure. Intermediate nodes SHOULD NOT attempt re-routing after failure.
端到端重新路由入口节点可能在故障后尝试重新路由。中间节点不应在故障后尝试重新路由。
Nodes detecting failures MUST report an error and SHOULD supply crankback information.
检测故障的节点必须报告错误，并应提供回退信息。
Boundary Re-routing Intermediate nodes MAY attempt re-routing after failure only if they are Area Border Routers or AS Border Routers (ABRs/ASBRs). The boundary (ABR/ASBR) can either decide to forward the error message upstream to the ingress LSR or try to select another egress boundary LSR. Other intermediate nodes SHOULD NOT attempt re-routing. Nodes detecting failures MUST report an error and SHOULD supply crankback information.
边界重路由中间节点仅当它们是区域边界路由器或作为边界路由器（ABR/ASBR）时，才会在故障后尝试重路由。边界（ABR/ASBR）可以决定将错误消息向上游转发到入口LSR，或者尝试选择另一个出口边界LSR。其他中间节点不应尝试重新路由。检测故障的节点必须报告错误，并应提供回退信息。
Segment-based Re-routing Any node MAY attempt re-routing after it receives an error report and before it passes the error report further upstream. Nodes detecting failures MUST report an error and SHOULD supply full crankback information.
基于段的重新路由任何节点都可以在收到错误报告后，在进一步向上游传递错误报告之前，尝试重新路由。检测故障的节点必须报告错误，并应提供完整的回退信息。
A node that detects the failure to setup an LSP or the failure of an established LSP SHOULD act according to the Re-routing Flag passed on the LSP setup request.
检测到LSP设置失败或已建立LSP失败的节点应根据LSP设置请求上传递的重新路由标志进行操作。
If Segment-based Re-routing is allowed, or if Boundary Re-routing is allowed and the detecting node is an ABR or ASBR, the detecting node MAY immediately attempt to re-route.
如果允许基于段的重路由，或者如果允许边界重路由并且检测节点是ABR或ASBR，则检测节点可以立即尝试重路由。
If End-to-end Re-routing is indicated, or if Segment-based or Boundary Re-routing is allowed and the detecting node chooses not to make re-routing attempts (or has exhausted all possible re-routing attempts), the detecting node MUST return a protocol error indication and SHOULD include full crankback information.
如果指示端到端重新路由，或者如果允许基于段或边界的重新路由，并且检测节点选择不进行重新路由尝试（或已用尽所有可能的重新路由尝试），则检测节点必须返回协议错误指示，并应包括完整的回退信息。
Each repair point SHOULD apply a locally configurable limit to the number of attempts it makes to re-route an LSP. This helps to prevent excessive network usage in the event of significant faults, and allows back-off to other repair points which may have a better chance of routing around the problem.
每个维修点应对其尝试重新路由LSP的次数应用本地可配置的限制。这有助于防止在发生重大故障时过度使用网络，并允许退回到其他修复点，这些修复点可能有更好的机会围绕问题进行路由。
An error code/value of "Routing Problem"/"Re-routing limit exceeded" (24/22) is used to identify that a node has abandoned crankback re-routing because it has reached a threshold for retry attempts.
“路由问题”/“超出重新路由限制”（24/22）的错误代码/值用于标识节点已放弃回退重新路由，因为它已达到重试尝试的阈值。
A node receiving an error response with this status code MAY also attempt crankback re-routing, but it is RECOMMENDED that such attempts be limited to the ingress LSR.
接收到此状态代码的错误响应的节点也可能尝试回退重新路由，但建议此类尝试仅限于入口LSR。
The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path messages to convey the Re-Routing Flag described in Section 4.1. Three bits are defined for inclusion in the LSP Attributes TLV as follows. The bit numbers below have been assigned by IANA.
[RFC4420]中定义的LSP_属性对象用于路径消息，以传递第4.1节中描述的重路由标志。LSP属性TLV中包含的三位定义如下。下面的位号由IANA分配。
Bit Name and Usage Number
位名称和使用编号
1 End-to-end re-routing desired. This flag indicates the end-to-end re-routing behavior for an LSP under establishment. This MAY also be used for specifying the behavior of end-to-end LSP recovery for established LSPs.
1需要端到端重新布线。此标志表示正在建立的LSP的端到端重新路由行为。这也可用于指定已建立LSP的端到端LSP恢复行为。
2 Boundary re-routing desired. This flag indicates the boundary re-routing behavior for an LSP under establishment. This MAY also be used for specifying the segment-based LSP recovery through nested crankback for established LSPs. The boundary ABR/ASBR can either decide to forward the PathErr message upstream to an upstream boundary ABR/ASBR or to the ingress LSR. Alternatively, it can try to select another egress boundary LSR.
2.需要边界重新布线。此标志表示正在建立的LSP的边界重路由行为。这也可用于通过已建立LSP的嵌套回退指定基于段的LSP恢复。边界ABR/ASBR可以决定向上游边界ABR/ASBR或入口LSR转发PathErr消息。或者，它可以尝试选择另一个出口边界LSR。
3 Segment-based re-routing desired. This flag indicates the segment-based re-routing behavior for an LSP under establishment. This MAY also be used to specify the segment-based LSP recovery for established LSPs.
3需要基于段的重新布线。此标志表示正在建立的LSP的基于段的重新路由行为。这也可用于为已建立的LSP指定基于段的LSP恢复。
As described above, full crankback information SHOULD indicate the node, link, and other resources, which have been attempted but have failed because of allocation issues or network failure.
如上所述，完整的回退信息应指示节点、链路和其他资源，这些资源已尝试过，但由于分配问题或网络故障而失败。
The default crankback information SHOULD include the interface and the node address.
默认回退信息应包括接口和节点地址。
Any address reported in such crankback information SHOULD be an address that was distributed by the routing protocols (OSPF and IS-IS) in their TE link state advertisements. However, some additional information such as component link identifiers is additional to this.
此类回溯信息中报告的任何地址都应该是路由协议（OSPF和IS-IS）在其TE链路状态播发中分发的地址。然而，一些附加的标识符是附加的，例如该组件的附加标识符。
[RFC3473] defines an IF_ID ERROR_SPEC object that can be used on PathErr, ResvErr and Notify messages to convey the information carried in the Error Spec Object defined in [RFC3209]. Additionally, the IF_ID ERROR_SPEC Object has the scope for carrying TLVs that identify the link associated with the error.
[RFC3473]定义了一个IF_ID ERROR_SPEC对象，该对象可用于PathErr、ResvErr和Notify消息，以传递[RFC3209]中定义的错误规范对象中包含的信息。此外，IF_ID ERROR_SPEC对象具有承载TLV的范围，TLV标识与错误关联的链接。
The TLVs for use with this object are defined in [RFC3471], and are listed below. They are used in two places. In the IF_ID RSVP_HOP object they are used to identify links. In the IF_ID ERROR_SPEC object they are used to identify the failed resource which is usually the downstream resource from the reporting node.
[RFC3471]中定义了用于此对象的TLV，如下所示。它们用于两个地方。在IF_ID RSVP_HOP对象中，它们用于标识链接。在IF_ID ERROR_SPEC对象中，它们用于标识失败的资源，通常是来自报告节点的下游资源。
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be used to identify component interfaces in IF_ID ERROR_SPEC objects.
注意，TLV4和5已被[RFC4201]淘汰，不应用于标识IF_ID ERROR_SPEC对象中的组件接口。
In order to facilitate reporting of crankback information, the following additional TLVs are defined.
为了便于报告拖转信息，定义了以下附加TLV。
Type Length Format Description
--------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label)
7 var See below UPSTREAM_LABEL (GMPLS label)
8 8 See below NODE_ID (TE Router ID)
9 x See below OSPF_AREA (Area ID)
10 x See below ISIS_AREA (Area ID)
11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
12 var See below ERO_CONTEXT (ERO subobject)
13 var See below ERO_NEXT_CONTEXT (ERO subobjects)
14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address)
15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address)
16 8 IPv4 Addr. INCOMING_IPv4 (Interface address)
17 20 IPv6 Addr. INCOMING_IPv6 (Interface address)
18 12 Compound INCOMING_IF_INDEX (Interface index)
19 var See below INCOMING_DOWN_LABEL (GMPLS label)
20 var See below INCOMING_UP_LABEL (GMPLS label)
21 8 See below REPORTING_NODE_ID (Router ID)
22 x See below REPORTING_OSPF_AREA (Area ID)
23 x See below REPORTING_ISIS_AREA (Area ID)
24 8 See below REPORTING_AS (Autonomous system)
25 var See below PROPOSED_ERO (ERO subobjects)
26 var See below NODE_EXCLUSIONS (List of nodes)
27 var See below LINK_EXCLUSIONS (List of interfaces)
Type Length Format Description
--------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label)
7 var See below UPSTREAM_LABEL (GMPLS label)
8 8 See below NODE_ID (TE Router ID)
9 x See below OSPF_AREA (Area ID)
10 x See below ISIS_AREA (Area ID)
11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
12 var See below ERO_CONTEXT (ERO subobject)
13 var See below ERO_NEXT_CONTEXT (ERO subobjects)
14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address)
15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address)
16 8 IPv4 Addr. INCOMING_IPv4 (Interface address)
17 20 IPv6 Addr. INCOMING_IPv6 (Interface address)
18 12 Compound INCOMING_IF_INDEX (Interface index)
19 var See below INCOMING_DOWN_LABEL (GMPLS label)
20 var See below INCOMING_UP_LABEL (GMPLS label)
21 8 See below REPORTING_NODE_ID (Router ID)
22 x See below REPORTING_OSPF_AREA (Area ID)
23 x See below REPORTING_ISIS_AREA (Area ID)
24 8 See below REPORTING_AS (Autonomous system)
25 var See below PROPOSED_ERO (ERO subobjects)
26 var See below NODE_EXCLUSIONS (List of nodes)
27 var See below LINK_EXCLUSIONS (List of interfaces)
For types 1, 2, and 3 the format of the Value field is already defined in [RFC3471].
对于类型1、2和3，值字段的格式已在[RFC3471]中定义。
For types 14 and 16, the format of the Value field is the same as for type 1.
对于类型14和16，值字段的格式与类型1相同。
For types 15 and 17, the format of the Value field is the same as for type 2.
对于类型15和17，值字段的格式与类型2相同。
For type 18, the format of the Value field is the same as for type 3.
对于类型18，值字段的格式与类型3相同。
For types 6, 7, 19, and 20, the length field is variable and the Value field is a label as defined in [RFC3471]. As with all uses of labels, it is assumed that any node that can process the label information knows the syntax and semantics of the label from the context. Note that all TLVs are zero-padded to a multiple of four octets so that if a label is not itself a multiple of four octets, it must be disambiguated from the trailing zero pads by knowledge derived from the context.
对于类型6、7、19和20，长度字段是可变的，值字段是[RFC3471]中定义的标签。与标签的所有用途一样，假设任何能够处理标签信息的节点都从上下文中知道标签的语法和语义。请注意，所有TLV都是四个八位字节的倍数的零填充，因此，如果标签本身不是四个八位字节的倍数，则必须通过从上下文中获得的知识将其从尾部零填充中消除歧义。
For types 8 and 21, the Value field has the format:
对于类型8和21，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID: 32 bits
路由器ID:32位
The TE Router ID (TLV type 8) or the Router ID (TLV type 21) used to identify the node within the IGP.
用于标识IGP内节点的TE路由器ID（TLV类型8）或路由器ID（TLV类型21）。
For types 9 and 22, the Value field has the format:
对于类型9和22，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF Area Identifier
OSPF区域标识符
The 4-octet area identifier for the node. This identifies the area where the failure has occurred.
节点的4个八位组区域标识符。这标识了发生故障的区域。
For types 10 and 23, the Value field has the format:
对于类型10和23，值字段的格式为：
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 | IS-IS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IS-IS Area Identifier (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | IS-IS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IS-IS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
长
Length of the actual (non-padded) IS-IS Area Identifier in octets. Valid values are from 2 to 11 inclusive.
实际（非填充）IS-IS区域标识符的长度（以八位字节为单位）。有效值介于2到11之间（含2到11）。
IS-IS Area Identifier
IS-IS区域标识符
The variable-length IS-IS area identifier. Padded with trailing zeroes to a four-octet boundary.
可变长度IS-IS区域标识符。用尾随零填充到四个八位组边界。
For types 11 and 24, the Value field has the format:
对于类型11和24，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Autonomous System Number: 32 bits
自治系统编号：32位
The AS Number of the associated Autonomous System. Note that if 16-bit AS numbers are in use, the low order bits (16 through 31) should be used and the high order bits (0 through 15) should be set to zero.
关联自治系统的AS编号。注意，如果使用16位AS数字，则应使用低阶位（16至31），高阶位（0至15）应设置为零。
For types 12, 13, and 25, the Value field has the format:
对于类型12、13和25，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ERO Subobjects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ERO Subobjects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERO Subobjects:
ERO子对象：
A sequence of Explicit Route Object (ERO) subobjects. Any ERO subobjects are allowed whether defined in [RFC3209], [RFC3473], or other documents. Note that ERO subobjects contain their own types and lengths.
显式路由对象（ERO）子对象的序列。无论[RFC3209]、[RFC3473]或其他文件中是否定义，都允许使用任何ERO子对象。请注意，ERO子对象包含它们自己的类型和长度。
For type 26, the Value field has the format:
对于类型26，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Node Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Node Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Identifiers:
节点标识符：
A sequence of TLVs as defined here of types 1, 2, or 8 that indicates downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt. Note that an interface identifier may be used to identify a node.
此处定义的类型为1、2或8的TLV序列，表示已参与回退尝试的下游节点，并且已被声明为不可用于当前LSP设置尝试。注意，接口标识符可用于标识节点。
For type 27, the Value field has the format:
对于类型27，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Link Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Link Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifiers:
链接标识符：
A sequence of TLVs as defined here of the same format as type 1, 2 or 3 TLVs that indicate incoming interfaces at downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt.
此处定义的一系列TLV，其格式与类型1、2或3 TLV相同，表示下游节点处的传入接口，这些接口已经参与了回退尝试，并且已被宣布无法用于当前LSP设置尝试。
If crankback is not being used, inclusion of an IF_ID ERROR_SPEC object in PathErr, ResvErr, and Notify messages follows the processing rules defined in [RFC3473] and [RFC4201]. A sender MAY include additional TLVs of types 6 through 27 to report crankback information for informational/monitoring purposes.
如果未使用回退，则在PathErr、ResvErr和Notify消息中包含If_ID ERROR_SPEC对象将遵循[RFC3473]和[RFC4201]中定义的处理规则。发送方可包括类型6至27的附加TLV，以报告回退信息，以供参考/监控。
If crankback is being used, the sender of a PathErr, ResvErr, or Notify message MUST use the IF_ID ERROR_SPEC object and MUST include at least one of the TLVs in the range 1 through 3 as described in [RFC3473], [RFC4201], and the previous paragraph. Additional TLVs SHOULD also be included to report further information. The following section gives advice on which TLVs should be used under different circumstances, and which TLVs must be supported by LSRs.
如果正在使用回退，PathErr、ResvErr或Notify消息的发送方必须使用If_ID ERROR_SPEC对象，并且必须包括[RFC3473]、[RFC4201]和上一段中所述范围1到3的至少一个TLV。还应包括其他TLV，以报告更多信息。以下部分给出了在不同情况下应使用哪些TLV以及LSR必须支持哪些TLV的建议。
Note that all such additional TLVs are optional and MAY be omitted. Inclusion of the optional TLVs SHOULD be performed where doing so helps to facilitate error reporting and crankback. The TLVs fall into three categories: those that are essential to report the error, those that provide additional information that is or may be
请注意，所有此类附加TLV都是可选的，可以省略。在有助于促进错误报告和回退的情况下，应包含可选TLV。TLV分为三类：报告错误所必需的TLV，提供当前或可能存在错误的附加信息的TLV
fundamental to the utility of crankback, and those that provide additional information that may be useful for crankback in some circumstances.
对于回退的实用性至关重要，以及那些提供在某些情况下可能对回退有用的附加信息的工具。
Note that all LSRs MUST be prepared to receive and forward any TLV as per [RFC3473]. This includes TLVs of type 4 or 5 as defined in [RFC3473] and obsoleted by [RFC4201]. There is, however, no requirement for an LSR to actively process any but the TLVs defined in [RFC3473]. An LSR that proposes to perform crankback re-routing SHOULD support receipt and processing of all of the fundamental crankback TLVs, and is RECOMMENDED to support the receipt and processing of the additional crankback TLVs.
请注意，所有LSR必须准备好按照[RFC3473]接收和转发任何TLV。这包括[RFC3473]中定义并由[RFC4201]淘汰的类型4或5的TLV。但是，除[RFC3473]中定义的TLV外，无需LSR主动处理任何TLV。建议执行回退重新路由的LSR应支持所有基本回退TLV的接收和处理，并建议支持额外回退TLV的接收和处理。
It should be noted, however, that some assumptions about the TLVs that will be used MAY be made based on the deployment scenarios. For example, a router that is deployed in a single-area network does not need to support the receipt and processing of TLV types 22 and 23. Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would not need to be processed by the receiver of a PathErr message.
但是，应注意的是，可能会根据部署场景对将使用的TLV进行一些假设。例如，部署在单区域网络中的路由器不需要支持TLV类型22和23的接收和处理。这些TLV可能会插入到IF_ID ERROR_SPEC对象中，但不需要由PathErr消息的接收者进行处理。
Error Report TLVs are those in the range 1 through 3. (Note that the obsoleted TLVs 4 and 5 may be considered in this category, but SHOULD NOT be used.)
错误报告TLV是介于1到3之间的TLV。（注意，淘汰的TLV 4和5可被视为该类别，但不应使用。）
As stated above, when crankback information is reported, the IF_ID ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is used, at least one of the TLVs in the range 1 through 3 MUST be present. The choice of which TLV to use will be dependent on the circumstance of the error and device capabilities. For example, a device that does not support IPv6 will not need the ability to create a TLV of type 2. Note, however, that such a device MUST still be prepared to receive and process all error report TLVs.
如上所述，报告回溯信息时，必须使用IF_ID ERROR_SPEC对象。使用IF_ID ERROR_SPEC对象时，必须至少存在范围1到3中的一个TLV。使用哪种TLV取决于错误情况和设备能力。例如，不支持IPv6的设备将不需要能够创建类型2的TLV。但是，请注意，此类设备仍必须准备好接收和处理所有错误报告TLV。
Many of the TLVs report the specific resource that has failed. For example, TLV type 1 can be used to report that the setup attempt was blocked by some form of resource failure on a specific interface identified by the IP address supplied. TLVs in this category are 1 through 11, although TLVs 4 and 5 may be considered to be excluded from this category by dint of having been obsoleted.
许多TLV报告发生故障的特定资源。例如，TLV type 1可用于报告安装尝试被提供的IP地址标识的特定接口上某种形式的资源故障阻止。该类别中的TLV为1至11，尽管TLV 4和5可能因已被淘汰而被视为不属于该类别。
These TLVs SHOULD be supplied whenever the node detecting and reporting the failure with crankback information has the information available. (Note that some of these TLVs MUST be included as described in the previous two sections.)
只要检测和报告故障的节点具有可用的信息，并且具有回退信息，就应该提供这些TLV。（注意，如前两节所述，必须包括其中一些TLV。）
The TLVs of type 8, 9, 10, and 11 MAY, however, be omitted according to local policy and relevance of the information.
但是，根据当地政策和信息的相关性，可以省略8、9、10和11类TLV。
Some TLVs help to locate the fault within the context of the path of the LSP that was being set up. TLVs of types 12, 13, 14, and 15 help to set the context of the error within the scope of an explicit path that has loose hops or non-precise abstract nodes. The ERO context information is not always a requirement, but a node may notice that it is a member of the next hop in the ERO (such as a loose or non-specific abstract node) and deduce that its upstream neighbor may have selected the path using next hop routing. In this case, providing the ERO context will be useful to the upstream node that performs re-routing.
一些TLV有助于在正在设置的LSP路径的上下文中定位故障。类型12、13、14和15的TLV有助于在具有松散跃点或非精确抽象节点的显式路径范围内设置错误的上下文。ERO上下文信息并不总是一项要求，但节点可能会注意到它是ERO中下一跳的成员（例如松散或非特定的抽象节点），并推断其上游邻居可能已经使用下一跳路由选择了路径。在这种情况下，提供ERO上下文将对执行重路由的上游节点有用。
Note the distinction between TLVs 12 and 13 is the distinction between "this is the hop I was trying to satisfy when I failed" and "this is the next hop I was trying to reach when I failed".
注意TLV 12和13之间的区别是“这是我失败时试图满足的跃点”和“这是我失败时试图达到的下一个跃点”之间的区别。
Reporting nodes SHOULD also supply TLVs from the range 12 through 20 as appropriate for reporting the error. The reporting nodes MAY also supply TLVs from the range 21 through 27.
报告节点还应提供范围为12到20的TLV，以报告错误。报告节点还可以提供范围21到27的tlv。
Note that in deciding whether a TLV in the range 12 through 20 "is appropriate", the reporting node should consider amongst other things, whether the information is pertinent to the cause of the failure. For example, when a cross-connection fails, it may be that the outgoing interface is faulted, in which case only the interface (for example, TLV type 1) needs to be reported, but if the problem is that the incoming interface cannot be connected to the outgoing interface because of temporary or permanent cross-connect limitations, the node should also include reference to the incoming interface (for example, TLV type 16).
请注意，在决定范围12到20中的TLV是否合适时，报告节点应考虑其他事项，即该信息是否与故障的原因有关。例如，当交叉连接失败时，可能是传出接口出现故障，在这种情况下，只需报告接口（例如，TLV类型1），但如果问题是由于临时或永久性交叉连接限制，传入接口无法连接到传出接口，节点还应包括对传入接口的引用（例如，TLV类型16）。
Four TLVs (21, 22, 23, and 24) allow the location of the reporting node to be expanded upon. These TLVs would not be included if the information is not of use within the local system, but might be added by ABRs relaying the error. Note that the Reporting Node ID (TLV 21) need not be included if the IP address of the reporting node as indicated in the ERROR_SPEC itself, is sufficient to fully identify the node.
四个TLV（21、22、23和24）允许扩展报告节点的位置。如果信息在本地系统内不可用，则不包括这些TLV，但可能通过ABR中继错误来添加这些TLV。请注意，如果报告节点的IP地址（如错误规范本身所示）足以完全标识该节点，则无需包括报告节点ID（TLV 21）。
The last three TLVs (25, 26, and 27) provide additional information for recomputation points. The reporting node (or a node forwarding the error) MAY make suggestions about how the error could have been avoided, for example, by supplying a partial ERO that would cause the LSP to be successfully set up if it were used. As the error
最后三个TLV（25、26和27）为重新计算点提供了附加信息。报告节点（或转发错误的节点）可以就如何避免错误提出建议，例如，通过提供部分ERO，如果使用LSP，将导致成功设置LSP。作为错误
propagates back upstream and as crankback routing is attempted and fails, it is beneficial to collect lists of failed nodes and links so that they will not be included in further computations performed at upstream nodes. These lists may also be factored into route exclusions [RFC4874].
向上游传播，当尝试回退路由并失败时，收集失败节点和链路的列表是有益的，这样它们就不会包含在上游节点执行的进一步计算中。这些清单也可纳入路线排除范围[RFC4874]。
Note that there is no ordering requirement on any of the TLVs within the IF_ID Error Spec, and no implication should be drawn from the ordering of the TLVs in a received IF_ID Error Spec.
请注意，IF_ID错误规范中没有对任何TLV的订购要求，并且不应从收到的IF_ID错误规范中的TLV订购中得出任何含义。
The decision of precisely which TLV types a reporting node includes is dependent on the specific capabilities of the node, and is outside the scope of this document.
报告节点具体包括哪种TLV类型的决定取决于该节点的特定功能，不在本文档的范围内。
Further guidance as to the inclusion of crankback TLVs can be given by grouping the TLVs according to the location of the failure and the context within which it is reported. For example, a TLV that reports an area identifier would only need to be included as the crankback error report transits an area boundary.
可通过根据故障位置和报告环境对TLV进行分组，提供关于包含回转TLV的进一步指导。例如，报告区域标识符的TLV只需要在回退错误报告传输区域边界时包含。
Resource Failure 6 DOWNSTREAM_LABEL 7 UPSTREAM_LABEL Interface Failures 1 IPv4 2 IPv6 3 IF_INDEX 4 COMPONENT_IF_DOWNSTREAM (obsoleted) 5 COMPONENT_IF_UPSTREAM (obsoleted) 12 ERO_CONTEXT 13 ERO_NEXT_CONTEXT 14 PREVIOUS_HOP_IPv4 15 PREVIOUS_HOP_IPv6 16 INCOMING_IPv4 17 INCOMING_IPv6 18 INCOMING_IF_INDEX 19 INCOMING_DOWN_LABEL 20 INCOMING_UP_LABEL Node Failures 8 NODE_ID 21 REPORTING_NODE_ID Area Failures 9 OSPF_AREA 10 ISIS_AREA 22 REPORTING_OSPF_AREA 23 REPORTING_ISIS_AREA 25 PROPOSED_ERO 26 NODE_EXCLUSIONS 27 LINK_EXCLUSIONS AS Failures 11 AUTONOMOUS_SYSTEM 24 REPORTING_AS
资源故障6下游标签7上游标签接口故障1 IPv4 2 IPv6 3如果索引4组件如果下游（过时）5组件如果上游（过时）12 ERO_上下文13 ERO_下一个_上下文14上一个_-HOP_IPv4 15上一个_-HOP_IPv6 16传入_-IPv4 17传入_-IPv6 18传入_-IF_索引19传入_-DOWN_标签20传入_-UP_标签节点故障8节点ID 21报告_-Node_ID区域故障9 OSPF_区域10 ISIS_区域22报告_-OSPF区域23报告_-ISIS_区域25建议的_-ERO 26节点排除27链路故障排除11自动系统24报告故障
Although discussion of aggregation of crankback information is out of the scope of this document, it should be noted that this topic is closely aligned to the information presented here. Aggregation is discussed further in Section 6.4.5.
尽管对回溯信息聚合的讨论超出了本文档的范围，但应注意，本主题与此处提供的信息密切相关。第6.4.5节将进一步讨论聚合。
No new object is used to distinguish between Path/Resv messages for an alternate LSP. Thus, the alternate LSP uses the same SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial LSP under re-routing.
没有新对象用于区分备用LSP的Path/Resv消息。因此，备用LSP使用与重新路由下初始LSP相同的会话和发送方模板/过滤器规格对象。
As described in Section 2, a node receiving crankback information in a PathErr must first check to see whether it is allowed to perform re-routing. This is indicated by the Re-routing Flags in the LSP_ATTRIBUTES object during an LSP setup request.
如第2节所述，在PathErr中接收回退信息的节点必须首先检查是否允许执行重新路由。这由LSP设置请求期间LSP_属性对象中的重路由标志指示。
If a node is not allowed to perform re-routing it should forward the PathErr message, or if it is the ingress report the LSP as having failed.
如果不允许节点执行重新路由，则应转发PathErr消息，或者如果是入口，则报告LSP失败。
If re-routing is allowed, the node should attempt to compute a path to the destination using the original (received) explicit path and excluding the failed/blocked node/link. The new path should be added to an LSP setup request as an explicit route and signaled.
如果允许重新路由，则节点应尝试使用原始（接收到的）显式路径计算到目标的路径，并排除故障/阻塞的节点/链路。新路径应作为显式路由添加到LSP设置请求中，并发出信号。
LSRs performing crankback re-routing should store all received crankback information for an LSP until the LSP is successfully established or until the node abandons its attempts to re-route the LSP. On the next crankback re-routing path computation attempt, the LSR should exclude all the failed nodes, links and resources reported from previous attempts.
执行回退重新路由的LSR应存储LSP的所有接收回退信息，直到成功建立LSP或直到节点放弃重新路由LSP的尝试。在下一次重新启动路由路径计算尝试中，LSR应排除以前尝试中报告的所有失败节点、链路和资源。
It is an implementation decision whether the crankback information is discarded immediately upon a successful LSP establishment or retained for a period in case the LSP fails.
在成功建立LSP后，是立即丢弃回退信息，还是在LSP失败时保留一段时间，这是一个实施决策。
In order to compute an alternate path by crankback re-routing, it is necessary to identify the blocked links or nodes and their locations. The common identifier of each link or node in an MPLS network should be specified. Both protocol-independent and protocol-dependent identifiers may be specified. Although a general identifier that is independent of other protocols is preferable, there are a couple of restrictions on its use as described in the following subsection.
为了通过回退重路由计算备用路径，有必要识别阻塞的链路或节点及其位置。应指定MPLS网络中每个链路或节点的公共标识符。可以指定协议独立标识符和协议依赖标识符。尽管独立于其他协议的通用标识符是可取的，但如以下小节所述，对其使用存在一些限制。
In link state protocols such as OSPF and IS-IS, each link and node in a network can be uniquely identified, for example, by the context of a TE Router ID and the Link ID. If the topology and resource information obtained by OSPF advertisements is used to compute a constraint-based path, the location of a blockage can be represented by such identifiers.
在诸如OSPF和IS-IS等链路状态协议中，网络中的每个链路和节点都可以唯一地识别，例如，通过TE路由器ID和链路ID的上下文来识别。如果使用OSPF播发获得的拓扑和资源信息来计算基于约束的路径，堵塞位置可由此类标识符表示。
Note that when the routing-protocol-specific link identifiers are used, the Re-routing Flag on the LSP setup request must have been set to show support for boundary or segment-based re-routing.
请注意，当使用路由协议特定的链路标识符时，LSP设置请求上的重新路由标志必须已设置为显示对基于边界或段的重新路由的支持。
In this document, we specify routing protocol specific link and node identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These identifiers may only be used if segment-based re-routing is supported, as indicated by the Routing Behavior flag on the LSP setup request.
在本文档中，我们为OSPFv2、OSPFv3以及IPv4和IPv6的IS-IS指定了路由协议特定的链路和节点标识符。如LSP设置请求上的路由行为标志所示，仅当支持基于段的重新路由时，才可以使用这些标识符。
The explicit route on the original LSP setup request may contain a loose or an Abstract Node. In these cases, the crankback information may refer to links or nodes that were not in the original explicit route.
原始LSP设置请求上的显式路由可能包含松散节点或抽象节点。在这些情况下，回退信息可能指不在原始显式路由中的链路或节点。
In order to compute a new path, the repair point may need to identify the pair of hops (or nodes) in the explicit route between which the error/blockage occurred.
为了计算新路径，修复点可能需要识别发生错误/阻塞的显式路由中的一对跳（或节点）。
To assist this, the crankback information reports the top two hops of the explicit route as received at the reporting node. The first hop will likely identify the node or the link, the second hop will identify a 'next' hop from the original explicit route.
为了帮助实现这一点，回溯信息报告在报告节点接收到的显式路由的前两个跃点。第一个跃点可能会标识节点或链路，第二个跃点将标识原始显式路由的“下一个”跃点。
When a node cannot or chooses not to perform crankback re-routing, it must forward the PathErr message further upstream.
当节点无法或选择不执行回退重新路由时，它必须将PathErr消息转发到更远的上游。
However, when a node was responsible for expanding or replacing the explicit route as the LSP setup was processed, it MUST update the crankback information with regard to the explicit route that it received. Only if this is done will the upstream nodes stand a chance of successfully routing around the problem.
但是，当处理LSP设置时，节点负责扩展或替换显式路由时，它必须更新与其接收的显式路由相关的回退信息。只有这样，上游节点才有机会成功地围绕问题进行路由。
When a setup blocking error or an error in an established LSP occurs and crankback information is sent in an error notification message, an upstream node may choose to attempt crankback re-routing. If that node's attempts at re-routing fail, the node will accumulate a set of failure information. When the node gives up, it MUST propagate the failure message further upstream and include crankback information when it does so.
当设置阻塞错误或已建立LSP中的错误发生并且在错误通知消息中发送回退信息时，上游节点可以选择尝试回退重新路由。如果该节点重新路由的尝试失败，该节点将积累一组失败信息。当节点放弃时，它必须进一步向上游传播故障消息，并在这样做时包含回退信息。
Including a full list of all failures that have occurred due to multiple crankback failures by multiple repair point LSRs downstream could lead to too much signaled information using the protocol extensions described in this document. A compression mechanism for such information is available using TLVs 26 and 27. These TLVs allow for a more concise accumulation of failure information as crankback failures are propagated upstream.
包括由于多个维修点LSR下游的多个拖转故障而发生的所有故障的完整列表可能会导致使用本文档中描述的协议扩展的信号信息过多。使用TLVs 26和27可获得此类信息的压缩机制。这些TLV允许在回转故障向上游传播时更简洁地积累故障信息。
Aggregation may involve reporting all links from a node as unusable by flagging the node as unusable, flagging an ABR as unusable when there is no downstream path available, or including a TLV of type 9 which results in the exclusion of the entire area, and so on. The precise details of how aggregation of crankback information is performed are beyond the scope of this document.
聚合可能涉及通过将节点标记为不可用、在没有下游路径可用时将ABR标记为不可用、或包括导致排除整个区域的类型9的TLV等方式将来自节点的所有链路报告为不可用。如何执行回溯信息聚合的确切细节超出了本文档的范围。
As described above, the resource allocation failure for RSVP-TE may occur on the reverse path when the Resv message is being processed. In this case, it is still useful to return the received crankback information to the ingress LSR. However, when the egress LSR receives the ResvErr message, per [RFC2205] it still has the option of re-issuing the Resv with different resource requirements (although not on an alternate path).
如上所述，当处理Resv消息时，RSVP-TE的资源分配失败可能发生在反向路径上。在这种情况下，将接收到的回退信息返回到入口LSR仍然有用。然而，当出口LSR收到ResvErr消息时，根据[RFC2205]，它仍然可以选择以不同的资源需求（尽管不是在备用路径上）重新发出Resv。
When a ResvErr carrying crankback information is received at an egress LSR, the egress LSR MAY ignore this object and perform the same actions that it would perform for any other ResvErr. However, if the egress LSR supports the crankback extensions defined in this document, and after all local recovery procedures have failed, it SHOULD generate a PathErr message carrying the crankback information and send it to the ingress LSR.
当在出口LSR处接收到携带回退信息的ResvErr时，出口LSR可忽略该对象并执行其将对任何其他ResvErr执行的相同动作。但是，如果出口LSR支持本文档中定义的回退扩展，并且在所有本地恢复过程失败后，它应该生成一条带有回退信息的PathErr消息，并将其发送到入口LSR。
If a ResvErr reports on more than one FILTER_SPEC (because the Resv carried more than one FILTER_SPEC) then only one set of crankback information should be present in the ResvErr and it should apply to all FILTER_SPEC carried. In this case, it may be necessary per [RFC2205] to generate more than one PathErr.
如果ResvErr报告了多个过滤器规格（因为Resv携带了多个过滤器规格），则ResvErr中只应存在一组回退信息，并且应适用于所有携带的过滤器规格。在这种情况下，可能需要按照[RFC2205]生成多个PathErr。
[RFC3473] defines the Notify message to enhance error reporting in RSVP-TE networks. This message is not intended to replace the PathErr and ResvErr messages. The Notify message is sent to addresses requested on the Path and Resv messages. These addresses could (but need not) identify the ingress and egress LSRs, respectively.
[RFC3473]定义通知消息，以增强RSVP-TE网络中的错误报告。此消息不用于替换PathErr和ResvErr消息。Notify消息被发送到Path和Resv消息上请求的地址。这些地址可以（但不需要）分别识别入口和出口LSR。
When a network error occurs, such as the failure of link hardware, the LSRs that detect the error MAY send Notify messages to the requested addresses. The type of error that causes a Notify message to be sent is an implementation detail.
当发生网络错误（如链路硬件故障）时，检测到错误的LSR可能会向请求的地址发送通知消息。导致发送Notify消息的错误类型是一个实现细节。
In the event of a failure, an LSR that supports [RFC3473] and the crankback extensions defined in this document MAY choose to send a Notify message carrying crankback information. This would ensure a speedier report of the error to the ingress and/or egress LSRs.
如果出现故障，支持[RFC3473]和本文档中定义的回退扩展的LSR可以选择发送包含回退信息的通知消息。这将确保更快地向入口和/或出口LSR报告错误。
Error values for the Error Code "Admission Control Failure" are defined in [RFC2205]. Error values for the error code "Routing Problem" are defined in [RFC3209] and [RFC3473].
错误代码“准入控制失败”的错误值在[RFC2205]中定义。错误代码“路由问题”的错误值在[RFC3209]和[RFC3473]中定义。
A new error value is defined for the error code "Routing Problem". "Re-routing limit exceeded" indicates that re-routing has failed because the number of crankback re-routing attempts has gone beyond the predetermined threshold at an individual LSR.
为错误代码“路由问题”定义了一个新的错误值。“超出重新路由限制”表示重新路由失败，因为在单个LSR上，回退重新路由尝试次数已超过预定阈值。
It is recognized that not all nodes in an RSVP-TE network will support the extensions defined in this document. It is important that an LSR that does not support these extensions can continue to process a PathErr, ResvErr, or Notify message even if it carries the newly defined IF_ID ERROR_SPEC information (TLVs).
众所周知，并非RSVP-TE网络中的所有节点都支持本文档中定义的扩展。重要的是，不支持这些扩展的LSR可以继续处理PathErr、ResvErr或Notify消息，即使它携带了新定义的if_ID ERROR_SPEC信息（TLV）。
This document does not introduce any backward compatibility issues provided that existing implementations conform to the TLV processing rules defined in [RFC3471] and [RFC3473].
如果现有实现符合[RFC3471]和[RFC3473]中定义的TLV处理规则，则本文档不会引入任何向后兼容性问题。
LSP recovery is performed to recover an established LSP when a failure occurs along the path. In the case of LSP recovery, the extensions for crankback re-routing explained above can be applied for improving performance. This section gives an example of applying the above extensions to LSP recovery. The goal of this example is to give a general overview of how this might work, and not to give a detailed procedure for LSP recovery.
执行LSP恢复是为了在路径发生故障时恢复已建立的LSP。在LSP恢复的情况下，可以应用上面解释的回退重路由扩展来提高性能。本节给出了将上述扩展应用于LSP恢复的示例。本示例的目的是对这可能的工作方式进行概述，而不是给出LSP恢复的详细过程。
Although there are several techniques for LSP recovery, this section explains the case of on-demand LSP recovery, which attempts to set up a new LSP on demand after detecting an LSP failure.
虽然有几种LSP恢复技术，但本节介绍了按需LSP恢复的情况，即在检测到LSP故障后，尝试按需建立新的LSP。
When an LSR detects a fault on an adjacent downstream link or node, a PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object may carry a Path_State_Remove_Flag indication. Each LSR receiving the message then releases the corresponding LSP. (Note that if the state removal indication is not present on the PathErr message, the ingress node MUST issue a PathTear message to cause the resources to be released.) If the failed LSP has to be recovered at an upstream LSR, the IF_ID ERROR SPEC that includes the location information of the failed link or node is included in the PathErr message. The ingress, intermediate area border LSR, or indeed any repair point permitted by the Re-routing Flags, that receives the PathErr message can terminate the message and then perform alternate routing.
当LSR在相邻下游链路或节点上检测到故障时，将向上游发送PathErr消息。在GMPLS中，ERROR_SPEC对象可能带有Path_State_Remove_标志指示。接收到消息的每个LSR随后释放相应的LSP。（请注意，如果PathErr消息上不存在状态删除指示，则入口节点必须发出PathTear消息以释放资源。）如果必须在上游LSR恢复失败的LSP，包含故障链接或节点位置信息的IF_ID错误规范包含在PathErr消息中。接收PathErr消息的入口、中间区域边界LSR，或者实际上是重路由标志允许的任何修复点，都可以终止消息，然后执行备用路由。
In a flat network, when the ingress LSR receives the PathErr message with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around the blocked link or node satisfying the QoS guarantees. If an alternate path is found, a new Path message is sent over this path toward the egress LSR.
在平面网络中，当入口LSR接收到带有IF_ID ERROR_SPEC tlv的PathErr消息时，它会计算满足QoS保证的阻塞链路或节点周围的备用路径。如果找到备用路径，则通过该路径向出口LSR发送新路径消息。
In a network segmented into areas, the following procedures can be used. As explained in Section 5.4, the LSP recovery behavior is indicated in the Flags field of the LSP_ATTRIBUTES object of the Path message. If the Flags indicate "End-to-end re-routing", the PathErr message is returned all the way back to the ingress LSR, which may then issue a new Path message along another path, which is the same procedure as in the flat network case above.
在划分为多个区域的网络中，可以使用以下步骤。如第5.4节所述，LSP恢复行为在路径消息的LSP_属性对象的标志字段中指示。如果标志指示“端到端重新路由”，则PathErr消息将一直返回到入口LSR，然后入口LSR可能会沿着另一条路径发出新的路径消息，这与上述平面网络案例中的过程相同。
If the Flags field indicates Boundary re-routing, the ingress area border LSR MAY terminate the PathErr message and then perform alternate routing within the area for which the area border LSR is the ingress LSR.
如果标志字段指示边界重新路由，则入口区域边界LSR可终止PathErr消息，然后在区域边界LSR为入口LSR的区域内执行备用路由。
If the Flags field indicates segment-based re-routing, any node MAY apply the procedures described above for Boundary re-routing.
如果标志字段指示基于段的重路由，则任何节点都可以应用上述步骤进行边界重路由。
This section only applies to errors that occur after an LSP has been established. Note that an LSR that generates a PathErr with Path_State_Remove Flag SHOULD also send a PathTear downstream to clean up the LSP.
本节仅适用于LSP建立后发生的错误。请注意，生成带有Path_State_Remove标志的PathErr的LSR还应向下游发送Path催泪以清理LSP。
A node that detects a fault and is downstream of the fault MAY send a PathErr and/or Notify message containing an IF_ID ERROR SPEC that includes the location information of the failed link or node, and MAY send a PathTear to clean up the LSP at all other downstream nodes.
检测到故障且位于故障下游的节点可发送PathErr和/或Notify消息，其中包含包含故障链路或节点的位置信息的IF_ID错误规范，并可发送Path撕裂以清除所有其他下游节点上的LSP。
However, if the reservation style for the LSP is Shared Explicit (SE) the detecting LSR MAY choose not to send a PathTear -- this leaves the downstream LSP state in place and facilitates make-before-break repair of the LSP re-utilizing downstream resources. Note that if the detecting node does not send a PathTear immediately, then the unused state will timeout according to the normal rules of [RFC2205].
然而，如果LSP的保留样式是共享显式（SE），则检测LSR可以选择不发送PathTear——这使下游LSP状态保持不变，并有助于LSP的先通后断修复重新利用下游资源。请注意，如果检测节点没有立即发送Path撕裂，则未使用状态将根据[RFC2205]的正常规则超时。
At a well-known merge point, an ABR or an ASBR, a similar decision might also be made so as to better facilitate make-before-break repair. In this case, a received PathTear might be 'absorbed' and not propagated further downstream for an LSP that has an SE reservation style. Note, however, that this is a divergence from the protocol and might severely impact normal tear-down of LSPs.
在一个众所周知的合并点，ABR或ASBR，也可以做出类似的决定，以便更好地促进先通后断的修复。在这种情况下，对于具有SE保留样式的LSP，接收到的PathTrain可能会被“吸收”，而不会进一步向下游传播。但是，请注意，这与协议不同，可能会严重影响LSP的正常拆除。
IANA maintains a registry called "RSVP Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". This subregistry includes the RSVP-TE "Routing Problem" error code that is defined in [RFC3209].
IANA维护一个名为“RSVP参数”的注册表，其中有一个子区名为“错误代码和全局定义的错误值子代码”。该子区域包括[RFC3209]中定义的RSVP-TE“路由问题”错误代码。
IANA has assigned a new error value for the "Routing Problem" error code as follows:
IANA为“路由问题”错误代码分配了一个新的错误值，如下所示：
22 Re-routing limit exceeded.
超过22个重新路由限制。
The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] are maintained by IANA in the "Interface_ID Types" subregistry of the "GMPLS Signaling Parameters" registry.
[RFC3471]中定义的IF_ID_ERROR_SPEC TLV类型值由IANA在“GMPLS信令参数”注册表的“Interface_ID Types”子区中维护。
IANA has made new assignments from this subregistry for the new TLV types defined in Section 6.2 of this document.
IANA已就该文件第6.2节中定义的新TLV类型从该分区域进行了新的分配。
IANA maintains an "RSVP TE Parameters" registry with an "Attributes Flags" subregistry. IANA has made three new allocations from this registry as listed in Section 5.4.
IANA维护一个带有“属性标志”子区的“RSVP TE参数”注册表。IANA已从该注册中心进行了三次新的分配，如第5.4节所列。
These bits are defined for inclusion in the LSP Attributes TLV of the LSP_ATTRIBUTES. The values shown have been assigned by IANA.
这些位定义为包含在LSP_属性的LSP属性TLV中。所示数值由IANA指定。
The RSVP-TE trust model assumes that RSVP-TE neighbors and peers trust each other to exchange legitimate and non-malicious messages. This assumption is necessary in order that the signaling protocol can function.
RSVP-TE信任模型假设RSVP-TE邻居和对等方相互信任以交换合法和非恶意消息。为了信令协议能够正常工作，这个假设是必要的。
Note that this trust model is assumed to cascade. That is, if an LSR trusts its neighbors, it extends this trust to all LSRs that its neighbor trusts. This means that the trust model is usually applied across the whole network to create a trust domain.
请注意，此信任模型假定为级联。也就是说，如果LSR信任其邻居，它会将此信任扩展到其邻居信任的所有LSR。这意味着信任模型通常应用于整个网络以创建信任域。
Authentication of neighbor identity is already a standard provision of RSVP-TE, as is the protection of messages against tampering and spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a description of applicable security considerations. These considerations and mechanisms are applicable to hop-by-hop message exchanges (such as used for crankback propagation on PathErr messages) and directed message exchanges (such as used for crankback propagation on Notify messages).
对邻居身份的认证已经是RSVP-TE的标准规定，保护消息免受篡改和欺骗也是如此。有关适用安全注意事项的说明，请参阅[RFC2205]、[RFC3209]和[RFC3473]。这些注意事项和机制适用于逐跳消息交换（例如用于PathErr消息上的回退传播）和定向消息交换（例如用于Notify消息上的回退传播）。
Key management may also be used with RSVP-TE to help to protect against impersonation and message content falsification. This requires the maintenance, exchange, and configuration of keys on each LSR. Note that such maintenance may be especially onerous to operators, hence it is important to limit the number of keys while ensuring the required level of security.
密钥管理也可与RSVP-TE一起使用，以帮助防止假冒和消息内容伪造。需要对每个LSR进行配置和维护。请注意，此类维护对操作员来说可能特别繁重，因此在确保所需安全级别的同时，限制钥匙数量非常重要。
This document does not introduce any protocol elements or message exchanges that change the operation of RSVP-TE security.
本文件不介绍任何改变RSVP-TE安全操作的协议元素或消息交换。
However, it should be noted that crankback is envisaged as an inter-domain mechanism, and as such it is likely that crankback information is exchanged over trust domain borders. In these cases, it is expected that the information from within a neighboring domain would be of little or no value to the node performing crankback re-routing and would be ignored. In any case, it is highly likely that the reporting domain will have applied some form of information aggregation in order to preserve the confidentiality of its network topology.
然而，应注意的是，回退被设想为一种域间机制，因此回退信息很可能在信任域边界上交换。在这些情况下，预期来自相邻域内的信息对执行回退重新路由的节点几乎没有价值或没有价值，并且将被忽略。在任何情况下，报告域很可能已经应用了某种形式的信息聚合，以保护其网络拓扑的机密性。
The issue of a direct attack by one domain upon another domain is possible and domain administrators should apply policies to protect their domains against the results of another domain attempting to thrash LSPs by allowing them to set up before reporting them as failed. On the whole, it is expected that commercial contracts between trust domains will provide a degree of protection.
一个域对另一个域的直接攻击是可能的，域管理员应应用策略保护其域不受另一个域试图攻击LSP的结果的影响，允许它们在报告LSP失败之前进行设置。总体而言，预计信任域之间的商业合同将提供一定程度的保护。
A more serious threat might arise if a domain reports that neither it nor its downstream neighbor can provide a path to the destination. Such a report could be bogus in that the reporting domain might not have allowed the downstream domain the chance to attempt to provide a path. Note that the same problem does not arise for nodes within a domain because of the trust model. This type of malicious behavior is hard to overcome, but may be detected by use of indirect path computation requests sent direct to the falsely reported domain using mechanisms such as the Path Computation Element [RFC4655].
如果域报告它或其下游邻居都无法提供到目标的路径，则可能会出现更严重的威胁。这样的报告可能是虚假的，因为报告域可能不允许下游域尝试提供路径。请注意，由于信任模型，域内的节点不会出现相同的问题。这种类型的恶意行为很难克服，但可以通过使用路径计算元素[RFC4655]等机制直接发送到错误报告的域的间接路径计算请求来检测。
Note that a separate document describing inter-domain MPLS and GMPLS security considerations will be produced.
请注意，将编制一份单独的文件，说明域间MPLS和GMPLS安全注意事项。
Finally, it should be noted that while the extensions in this document introduce no new security holes in the protocols, should a malicious user gain protocol access to the network, the crankback information might be used to prevent establishment of valid LSPs. Thus, the existing security features available in RSVP-TE should be carefully considered by all deployers and SHOULD be made available by all implementations that offer crankback. Note that the implementation of re-routing attempt thresholds are also particularly useful in this context.
最后，应该注意的是，虽然本文档中的扩展没有在协议中引入新的安全漏洞，但如果恶意用户获得对网络的协议访问权，回溯信息可能会用于防止建立有效的LSP。因此，所有部署人员都应该仔细考虑RSVP-TE中现有的安全特性，并且所有提供回退功能的实现都应该提供这些特性。请注意，在这种情况下，重新路由尝试阈值的实现也特别有用。
We would like to thank Juha Heinanen and Srinivas Makam for their review and comments, and Zhi-Wei Lin for his considered opinions. Thanks, too, to John Drake for encouraging us to resurrect this document and consider the use of the IF_ID ERROR SPEC object. Thanks for a welcome and very thorough review by Dimitri Papadimitriou.
我们要感谢Juha Heinanen和Srinivas Makam的审查和评论，以及林志伟深思熟虑的意见。同样感谢John Drake鼓励我们重启此文档并考虑使用IFIID错误规范对象。感谢Dimitri Papadimitriou的欢迎和非常全面的评论。
Stephen Shew made useful comments for clarification through the ITU-T liaison process.
Stephen Shew通过ITU-T联络过程提出了有益的澄清意见。
Simon Marshall-Unitt made contributions to this document.
Simon Marshall Unitt对此文件做出了贡献。
SecDir review was provided by Tero Kivinen. Thanks to Ross Callon for useful discussions of prioritization of crankback re-routing attempts.
SecDir审查由Tero Kivinen提供。感谢Ross Callon对回退重路由尝试的优先级进行了有益的讨论。
[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月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，J.-P.，和A.Ayyangar，“使用资源预留协议流量工程（RSVP-TE）建立多协议标签交换（MPLS）标签交换路径（LSP）的属性编码”，RFC 4420，2006年2月。
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS Routing & Related Traffic Engineering Methods for IP-, ATM-, & TDM-Based Multiservice Networks", May, 2002.
[ASH1]G.Ash，ITU-T建议E.360.1-->E.360.7，“基于IP、ATM和TDM的多服务网络的QoS路由和相关流量工程方法”，2002年5月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]Sharma，V.，Ed.，和F.Hellstrand，Ed.，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[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月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)", <af-pnni-0055.000>, May 1996.
[PNNI]ATM论坛，“专用网络接口规范1.0版（PNNI 1.0）”，<af-PNNI-0055.000>，1996年5月。
Experience of using release messages in TDM-based networks for analogous repair and re-routing purposes provides some guidance.
在基于TDM的网络中使用释放消息进行类似修复和重新路由的经验提供了一些指导。
One can use the receipt of a release message with a Cause Value (CV) indicating "link congestion" to trigger a re-routing attempt at the originating node. However, this sometimes leads to problems.
可以使用具有指示“链路拥塞”的原因值（CV）的释放消息的接收来触发发起节点处的重新路由尝试。然而，这有时会导致问题。
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
Figure 1. Example of network topology
图1。网络拓扑示例
Figure 1 illustrates four examples based on service-provider experiences with respect to crankback (i.e., explicit indication) versus implicit indication through a release with CV. In this example, N1, N2,N3, and N4 are located in one area (A-1), and AT, EO1, and EO2 are in another area (A-2).
图1展示了基于服务提供商经验的四个示例，分别是通过CV发布的回退（即显式指示）和隐式指示。在此示例中，N1、N2、N3和N4位于一个区域（A-1），AT、EO1和EO2位于另一个区域（A-2）。
Note that two distinct areas are used in this example to clearly expose the issues. In fact, the issues are not limited to multi-area networks, but arise whenever path computation is distributed throughout the network, for example, where loose routes, AS routes, or path computation domains are used.
请注意，本例中使用了两个不同的区域来清楚地暴露问题。事实上，问题不限于多区域网络，而是在路径计算分布在整个网络中时出现，例如，在使用松散路由、AS路由或路径计算域的情况下。
1. A connection request from node N1 to EO1 may route to N4 and then find "all circuits busy". N4 returns a release message to N1 with CV34 indicating all circuits busy. Normally, a node such as N1 is programmed to block a connection request when receiving CV34, although there is good reason to try to alternately route the connection request via N2 and N3.
1. 从节点N1到EO1的连接请求可以路由到N4，然后发现“所有电路忙”。N4向N1返回释放消息，CV34指示所有电路忙。通常，节点（如N1）被编程为在接收CV34时阻止连接请求，尽管有充分的理由尝试通过N2和N3交替路由连接请求。
Some service providers have implemented a technique called Route Advance (RA), where if a node that is RA capable receives a release message with CV34, it will use this as an implicit re-route indication and try to find an alternate route for the connection request if possible. In this example, alternate route N1-N2-N3-EO1 can be tried and may well succeed.
一些服务提供商已经实现了一种称为路由推进（RA）的技术，其中，如果具有RA能力的节点接收到带有CV34的释放消息，它将使用该消息作为隐式重新路由指示，并在可能的情况下尝试为连接请求找到备用路由。在此示例中，可以尝试备选路线N1-N2-N3-EO1，并且很可能成功。
2. Suppose a connection request goes from N2 to N3 to AT while trying to reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34 and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of course this fails again. The problem is that N2 does not realize where this blocking occurred based on the CV34, and in this case there is no point in further alternate routing.
2. 假设一个连接请求在试图到达EO2时从N2到N3再到AT，并且在链路AT-EO2处被阻塞。节点AT返回CV34，使用RA，N2可能会尝试重新路由N2-N1-N4-AT-EO2，但这当然会再次失败。问题是N2没有意识到基于CV34的阻塞发生在哪里，在这种情况下，没有进一步的备用路由。
3. However, in another case of a connection request from N2 to E02, suppose that link N3-AT is blocked. In this case N3 should return crankback information (and not CV34) so that N2 can alternate route to N1-N4-AT-EO2, which may well be successful.
3. 然而，在从N2到E02的连接请求的另一种情况下，假设链路N3-AT被阻塞。在这种情况下，N3应返回回退信息（而不是CV34），以便N2可以交替路由到N1-N4-AT-EO2，这很可能是成功的。
4. In a final example, for a connection request from EO1 to N2, EO1 first tries to route the connection request directly to N3. However, node N3 may reject the connection request even if there is bandwidth available on link N3-EO1 (perhaps for priority routing considerations, e.g., reserving bandwidth for high priority connection requests). However, when N3 returns CV34 in the release message, EO1 blocks the connection request (a normal response to CV34 especially if E01-N4 is already known to be blocked) rather than trying to alternate route through AT-N3-N2, which might be successful. If N3 returns crankback information, EO1 could respond by trying the alternate route.
4. 在最后一个示例中，对于从EO1到N2的连接请求，EO1首先尝试将连接请求直接路由到N3。然而，即使链路N3-EO1上存在可用带宽，节点N3也可以拒绝连接请求（可能出于优先级路由考虑，例如，为高优先级连接请求保留带宽）。但是，当N3在释放消息中返回CV34时，EO1会阻止连接请求（对CV34的正常响应，特别是当已知E01-N4已被阻止时），而不是尝试通过AT-N3-N2进行备用路由，这可能会成功。如果N3返回回退信息，EO1可以通过尝试备用路由进行响应。
It is certainly the case that with topology exchange, such as OSPF, the ingress LSR could infer the re-routing condition. However, convergence of routing information is typically slower than the expected LSP setup times. One of the reasons for crankback is to avoid the overhead of available-link-bandwidth flooding, and to more efficiently use local state information to direct alternate routing at the ingress-LSR.
当然，对于拓扑交换，例如OSPF，入口LSR可以推断出重路由条件。然而，路由信息的收敛通常比预期的LSP设置时间慢。回退的原因之一是避免可用链路带宽泛滥的开销，并更有效地使用本地状态信息来指导入口LSR处的备用路由。
[ASH1] shows how event-dependent-routing can just use crankback, and not available-link-bandwidth flooding, to decide on the re-route path in the network through "learning models". Reducing this flooding reduces overhead and can lead to the ability to support much larger AS sizes.
[ASH1]展示了事件相关路由如何通过“学习模型”使用回退和不可用链路带宽泛洪来决定网络中的重新路由路径。减少这种泛洪会减少开销，并能够支持更大的AS大小。
Therefore, the alternate routing should be indicated based on an explicit indication (as in examples 3 and 4), and it is best to know the following information separately:
因此，应根据明确指示指示备用路由（如例3和例4所示），最好分别了解以下信息：
a) where blockage/congestion occurred (as in examples 1-2)
a) 发生堵塞/堵塞的位置（如示例1-2所示）
and
和
b) whether alternate routing "should" be attempted even if there is no "blockage" (as in example 4).
b) 即使没有“阻塞”（如例4所示），是否也应尝试交替布线。
Authors' Addresses
作者地址
Adrian Farrel (Editor) Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
阿德里安·法雷尔（编辑）老狗咨询电话：+44（0）1978 860944电子邮件：adrian@olddog.co.uk
Arun Satyanarayana Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 Phone: +1 408 853-3206 EMail: asatyana@cisco.com
Arun Satyanarayana Cisco系统公司170 West Tasman Dr.San Jose，CA 95134电话：+1 408 853-3206电子邮件：asatyana@cisco.com
Atsushi Iwata NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2744 Fax: +81-(44)-431-7612 EMail: a-iwata@ah.jp.nec.com
岩田日本电气公司系统平台研究实验室1753 Shimonumabe Nakahara ku，Kanagawa Kawaki，211-8666，日本电话：+81-（44）-396-2744传真：+81-（44）-431-7612电子邮件：a-iwata@ah.jp.nec.com
Norihito Fujita NEC Corporation System Platforms Research Laboratories 1753 Shimonumabe Nakahara-ku, Kawasaki, Kanagawa, 211-8666, JAPAN Phone: +81-(44)-396-2091 Fax: +81-(44)-431-7644 EMail: n-fujita@bk.jp.nec.com
藤田北仁NEC公司系统平台研究实验室1753 Shimonumabe Nakahara ku，Kanagawa川崎，211-8666，日本电话：+81-（44）-396-2091传真：+81-（44）-431-7644电子邮件：n-fujita@bk.jp.nec.com
Gerald R. Ash AT&T EMail: gash5107@yahoo.com
Gerald R.Ash AT&T电子邮件：gash5107@yahoo.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。