Network Working Group A. Farrel, Ed.
Request for Comments: 5151 Old Dog Consulting
Updates: 3209, 3473 A. Ayyangar
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
February 2008
Network Working Group A. Farrel, Ed.
Request for Comments: 5151 Old Dog Consulting
Updates: 3209, 3473 A. Ayyangar
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
February 2008
Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
域间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）。本备忘录的分发不受限制。
Abstract
摘要
This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.
本文档描述了在多协议标签交换流量工程（MPLS-TE）分组网络和通用MPLS（GMPLS）中使用资源预留协议流量工程（RSVP-TE）信令的过程和协议扩展支持跨域边界的标签交换路径的建立和维护的分组和非分组网络。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks.
在本文档中，域被视为地址空间或路径计算责任的公共领域内的任何网络元素集合。此类域的示例包括自治系统、内部网关协议（IGP）路由区域和GMPLS覆盖网络。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................4
2. Signaling Overview ..............................................4
2.1. Signaling Options ..........................................5
3. Procedures on the Domain Border Node ............................6
3.1. Rules on ERO Processing ....................................8
3.2. LSP Setup Failure and Crankback ...........................10
3.3. RRO Processing across Domains .............................11
3.4. Notify Message Processing .................................11
4. RSVP-TE Signaling Extensions ...................................12
4.1. Control of Downstream Choice of Signaling Method ..........12
5. Protection and Recovery of Inter-Domain TE LSPs ................13
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) ....14
5.1.1. Failure within a Domain (Link or Node Failure) .....14
5.1.2. Failure of Link at Domain Border ...................14
5.1.3. Failure of a Border Node ...........................15
5.2. Protection and Recovery of GMPLS LSPs .....................15
6. Reoptimization of Inter-Domain TE LSPs .........................16
7. Backward Compatibility .........................................17
8. Security Considerations ........................................18
9. IANA Considerations ............................................20
9.1. Attribute Flags for LSP_Attributes Object .................20
9.2. New Error Codes ...........................................20
10. Acknowledgments ...............................................21
11. References ....................................................21
11.1. Normative References ....................................21
11.2. Informative References ..................................22
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................4
2. Signaling Overview ..............................................4
2.1. Signaling Options ..........................................5
3. Procedures on the Domain Border Node ............................6
3.1. Rules on ERO Processing ....................................8
3.2. LSP Setup Failure and Crankback ...........................10
3.3. RRO Processing across Domains .............................11
3.4. Notify Message Processing .................................11
4. RSVP-TE Signaling Extensions ...................................12
4.1. Control of Downstream Choice of Signaling Method ..........12
5. Protection and Recovery of Inter-Domain TE LSPs ................13
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) ....14
5.1.1. Failure within a Domain (Link or Node Failure) .....14
5.1.2. Failure of Link at Domain Border ...................14
5.1.3. Failure of a Border Node ...........................15
5.2. Protection and Recovery of GMPLS LSPs .....................15
6. Reoptimization of Inter-Domain TE LSPs .........................16
7. Backward Compatibility .........................................17
8. Security Considerations ........................................18
9. IANA Considerations ............................................20
9.1. Attribute Flags for LSP_Attributes Object .................20
9.2. New Error Codes ...........................................20
10. Acknowledgments ...............................................21
11. References ....................................................21
11.1. Normative References ....................................21
11.2. Informative References ..................................22
The requirements for inter-area and inter-AS (Autonomous System) Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and [RFC4216], respectively. Many of these requirements also apply to Generalized MPLS (GMPLS) networks. The framework for inter-domain MPLS-TE is provided in [RFC4726].
[RFC4105]和[RFC4216]分别说明了区域间和AS间（自治系统）多协议标签交换（MPLS）流量工程（TE）的要求。其中许多要求也适用于通用MPLS（GMPLS）网络。域间MPLS-TE的框架在[RFC4726]中提供。
This document presents procedures and extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling for the setup and maintenance of traffic engineered Label Switched Paths (TE LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The signaling procedures described in this document are applicable to MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as described in [RFC3473].
本文档介绍了资源预留协议流量工程（RSVP-TE）信令的程序和扩展，用于在MPLS-TE或GMPLS网络中建立和维护跨多个域的流量工程标签交换路径（TE LSP）。本文件中描述的信令程序适用于使用RSVP-TE（[RFC3209]）建立的MPLS-TE分组LSP以及使用RSVP-TE GMPLS扩展的所有LSP（分组和非分组），如[RFC3473]中所述。
Three different signaling methods for inter-domain RSVP-TE signaling are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. Nested LSPs are established using the techniques described in [RFC4206] to carry the end-to-end LSP in a separate tunnel across each domain. Stitched LSPs are established using the procedures of [RFC5150] to construct an end-to-end LSP from the concatenation of separate LSPs each spanning a domain.
[RFC4726]中确定了域间RSVP-TE信令的三种不同信令方法。使用[RFC3209]和[RFC3473]中的过程来实现连续LSP，以创建一个跨所有域的端到端LSP。使用[RFC4206]中所述的技术建立嵌套LSP，以在每个域的单独隧道中承载端到端LSP。缝合LSP是使用[RFC5150]的程序建立的，以从每个跨越一个域的单独LSP的串联构造端到端LSP。
This document defines the RSVP-TE protocol extensions necessary to control and select which of the three signaling mechanisms is used for any one end-to-end inter-domain TE LSP.
本文件定义了控制和选择三种信令机制中的哪一种用于任何一个端到端域间TE LSP所需的RSVP-TE协议扩展。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas, and GMPLS overlay networks ([RFC4208]).
在本文档中，域被视为地址空间或路径计算责任的公共领域内的任何网络元素集合。此类域的示例包括自治系统、IGP区域和GMPLS覆盖网络（[RFC4208]）。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
AS: Autonomous System.
AS：自治系统。
ASBR: Autonomous System Border Router. A router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
ASBR：自治系统边界路由器。一种路由器，用于通过一个或多个AS间链路将不同或相同服务提供商的ASs连接在一起。
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
旁通隧道：用于保护通过公共设施的一组LSP的LSP。
ERO: Explicit Route Object.
ERO：显式路由对象。
FA: Forwarding Adjacency.
前向邻接。
LSR: Label Switching Router.
标签交换路由器。
MP: Merge Point. The node where bypass tunnels meet the protected LSP.
MP：合并点。旁通隧道与受保护LSP相交的节点。
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single link of the protected LSP.
NHOP旁路隧道：下一跳旁路隧道。备份隧道，绕过受保护LSP的单个链路。
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single node of the protected LSP.
NNHOP旁路隧道：下一跳旁路隧道。备份隧道，绕过受保护LSP的单个节点。
PLR: Point of Local Repair. The ingress of a bypass tunnel.
PLR：局部维修点。旁通隧道的入口。
RRO: Record Route Object.
记录路由对象。
TE link: Traffic Engineering link.
TE链接：交通工程链接。
The RSVP-TE signaling of a TE LSP within a single domain is described in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by one of three options as described in [RFC4726] and set out in the next section:
[RFC3209]和[RFC3473]中描述了单个域内TE LSP的RSVP-TE信令。域间TE LSP可由[RFC4726]中描述的三个选项之一支持，并在下一节中阐述：
- contiguous LSPs - nested LSPs - stitched LSPs.
- 连续LSP-嵌套LSP-缝合LSP。
In fact, as pointed out in [RFC4726], any combination of these three options may be used in the course of an end-to-end inter-domain LSP. That is, the options should be considered as per-domain transit options so that an end-to-end inter-domain LSP that starts in domain A, transits domains B, C, and D, and ends in domain E might use an
事实上，正如[RFC4726]中指出的，这三个选项的任何组合都可以在端到端域间LSP过程中使用。也就是说，应根据域传输选项考虑这些选项，以便从域A开始，传输域B、C和D，并在域E结束的端到端域间LSP可以使用
LSP that runs contiguously from the ingress in domain A, through domain B to the border with domain C. Domain C might be transited using the nested LSP option to reach the border with domain D, and domain D might be transited using the stitched LSP option to reach the border with domain E, from where a normal LSP runs to the egress.
从域A中的入口通过域B连续运行到域C边界的LSP。域C可以使用嵌套LSP选项传输到域D的边界，域D可以使用缝合LSP选项传输到域E的边界，正常LSP从该边界运行到出口。
This document describes the RSVP-TE signaling extensions required to select and control which of the three signaling mechanisms is used.
本文件描述了选择和控制使用三种信令机制中的哪一种所需的RSVP-TE信令扩展。
The specific protocol extensions required to signal each LSP type are described in other documents and are out of scope for this document. Similarly, the routing extensions and path computation techniques necessary for the establishment of inter-domain LSPs are out of scope. An implementation of a transit LSR is unaware of the options for inter-domain TE LSPs since it sees only TE LSPs. An implementation of a domain border LSR has to decide what mechanisms of inter-domain TE LSP support to include, but must in any case support contiguous inter-domain TE LSPs since this is the default mode of operation for RSVP-TE. Failure to support either or both of nested LSPs or stitched LSPs, restricts the operators options, but does not prevent the establishment of inter-domain TE LSPs.
其他文档中描述了向每种LSP类型发送信号所需的特定协议扩展，这些扩展超出了本文档的范围。类似地，建立域间lsp所需的路由扩展和路径计算技术也超出了范围。传输LSR的实现不知道域间TE LSP的选项，因为它只看到TE LSP。域边界LSR的实现必须决定要包括哪些域间TE LSP支持机制，但在任何情况下都必须支持连续的域间TE LSP，因为这是RSVP-TE的默认操作模式。无法支持嵌套LSP或缝合LSP中的一个或两个，将限制操作员选项，但不会阻止建立域间TE LSP。
There are three ways in which an RSVP-TE LSP could be signaled across multiple domains:
RSVP-TE LSP可通过三种方式跨多个域发送信号：
Contiguous A contiguous TE LSP is a single TE LSP that is set up across multiple domains using RSVP-TE signaling procedures described in [RFC3209] and [RFC3473]. No additional TE LSPs are required to create a contiguous TE LSP, and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. In particular, the TE LSP has the same RSVP-TE session and LSP ID at every LSR along its path.
连续TE LSP是使用[RFC3209]和[RFC3473]中描述的RSVP-TE信令过程跨多个域设置的单个TE LSP。创建连续的TE LSP不需要额外的TE LSP，并且沿着整个LSP路径维护TE LSP的相同RSVP-TE信息。特别地，TE LSP在其路径上的每个LSR处具有相同的RSVP-TE会话和LSP ID。
Nested One or more TE LSPs may be nested within another TE LSP as described in [RFC4206]. This technique can be used to nest one or more inter-domain TE LSPs into an intra-domain hierarchical LSP (H-LSP). The label stacking construct is used to achieve nesting in packet networks. In the rest of this document, the term H-LSP is used to refer to an LSP that allows other LSPs to be nested within it. An H-LSP may be advertised as a TE link within the same instance of the routing protocol as was used to advertise the TE links from which it was created, in which case it is a Forwarding Adjacency (FA) [RFC4206].
嵌套的一个或多个TE LSP可以嵌套在另一个TE LSP中，如[RFC4206]中所述。该技术可用于将一个或多个域间TE-LSP嵌套到域内分层LSP（H-LSP）中。标签堆叠结构用于在分组网络中实现嵌套。在本文档的其余部分中，术语H-LSP用于指允许在其中嵌套其他LSP的LSP。H-LSP可以作为路由协议的同一实例内的TE链路进行广告，该实例用于广告从中创建H-LSP的TE链路，在这种情况下，H-LSP是转发邻接（FA）[RFC4206]。
Stitched The concept of LSP stitching as well as the required signaling procedures are described in [RFC5150]. This technique can be used to stitch together shorter LSPs (LSP segments) to create a single, longer LSP. The LSP segments of an inter-domain LSP may be intra-domain LSPs or inter-domain LSPs.
缝合LSP缝合的概念以及所需的信号程序在[RFC5150]中描述。此技术可用于将较短的LSP（LSP段）缝合在一起，以创建单个较长的LSP。域间LSP的LSP段可以是域内LSP或域间LSP。
The process of stitching in the data plane results in a single, end-to-end contiguous LSP. But in the control plane, each segment is signaled as a separate LSP (with distinct RSVP sessions) and the end-to-end LSP is signaled as yet another LSP with its own RSVP session. Thus, the control plane operation for LSP stitching is very similar to that for nesting.
数据平面中的缝合过程会产生一个端到端的连续LSP。但在控制平面中，每个段作为单独的LSP（具有不同的RSVP会话）发送信号，而端到端LSP作为另一个LSP发送信号，具有其自己的RSVP会话。因此，LSP缝合的控制平面操作与嵌套非常相似。
An end-to-end inter-domain TE LSP may be achieved using one or more of the signaling techniques described. The choice is a matter of policy for the node requesting LSP setup (the ingress) and policy for each successive domain border node. On receipt of an LSP setup request (RSVP-TE Path message) for an inter-domain TE LSP, the decision of whether to signal the LSP contiguously or whether to nest or stitch it to another TE LSP depends on the parameters signaled from the ingress node and on the configuration of the local node.
可以使用所描述的一种或多种信令技术来实现端到端域间TE LSP。选择是请求LSP设置（入口）的节点的策略问题，以及每个后续域边界节点的策略问题。在接收到域间TE LSP的LSP设置请求（RSVP-TE Path消息）时，是否连续地向LSP发送信号或是否将其嵌套或缝合到另一个TE LSP的决定取决于从入口节点发送信号的参数和本地节点的配置。
The stitching segment LSP or H-LSP used to cross a domain may be pre-established or signaled dynamically based on the demand caused by the arrival of the inter-domain TE LSP setup request.
用于跨域的缝合段LSP或H-LSP可以基于域间TE LSP设置请求的到达引起的需求而预先建立或动态地发信号。
Whether an inter-domain TE LSP is contiguous, nested, or stitched is limited by the signaling methods supported by or configured on the intermediate nodes. It is usually the domain border nodes where this restriction applies since other transit nodes are oblivious to the mechanism in use. The ingress of the LSP may further restrict the choice by setting parameters in the Path message when it is signaled.
域间TE LSP是连续的、嵌套的还是缝合的受中间节点支持的或在中间节点上配置的信令方法的限制。这一限制通常适用于域边界节点，因为其他传输节点不知道所使用的机制。LSP的进入可以通过在发送信号时在路径消息中设置参数来进一步限制选择。
When a domain border node receives the RSVP Path message for an inter-domain TE LSP setup, it MUST carry out the following procedures before it can forward the Path message to the next node along the path:
当域边界节点接收到域间TE LSP设置的RSVP Path消息时，它必须执行以下步骤，然后才能将Path消息沿路径转发到下一个节点：
1. Apply policies for the domain and the domain border node. These policies may restrict the establishment of inter-domain TE LSPs. In case of a policy failure, the node SHOULD fail the setup and send a PathErr message with error code "Policy control failure"/ "Inter-domain policy failure".
1. 为域和域边界节点应用策略。这些策略可能会限制域间TE LSP的建立。在策略失败的情况下，节点应使设置失败，并发送错误代码为“策略控制失败”/“域间策略失败”的PathErr消息。
2. Determine the signaling method to be used to cross the domain. If the ingress node of the inter-domain TE LSP has specified restrictions on the methods to be used, these MUST be adhered to. Within the freedom allowed by the ingress node, the domain border node MAY choose any method according to local configuration and policies. If no resultant signaling method is available or allowed, the domain border node MUST send a PathErr message with an error code as described in Section 4.1.
2. 确定用于跨域的信令方法。如果域间TE LSP的入口节点对要使用的方法有特定的限制，则必须遵守这些限制。在入口节点允许的自由范围内，域边界节点可以根据本地配置和策略选择任何方法。如果没有可用或允许的结果信令方法，则域边界节点必须发送带有错误代码的PathErr消息，如第4.1节所述。
Thus, for example, an ingress may request a contiguous LSP because it wishes to exert maximal control over the LSP's path and to control when reoptimization takes place. But the operator of a transit domain may decide (for example) that only LSP stitching is allowed for exactly the reason that it gives the operator the chance to reoptimize their own domain under their own control. In this case, the policy applied at the entry to the transit domain will result in the return of a PathErr message and the ingress has a choice to:
因此，例如，入口可以请求连续LSP，因为它希望对LSP的路径施加最大控制，并控制何时发生重新优化。但是传输域的运营商可能会决定（例如）只允许LSP缝合，因为它让运营商有机会在自己的控制下重新优化自己的域。在这种情况下，在传输域入口应用的策略将导致返回PathErr消息，入口可以选择：
- find another path avoiding the transit domain, - relax his requirements, or - fail to provide the service.
- 找到另一条避开中转域的路径，-放宽他的要求，或者-无法提供服务。
3. Carry out ERO procedures as described in Section 3 in addition to the procedures in [RFC3209] and [RFC3473].
3. 除[RFC3209]和[RFC3473]中的程序外，执行第3节中所述的ERO程序。
4. Perform any path computations as required to determine the path across the domain and potentially to select the exit point from the domain.
4. 根据需要执行任何路径计算，以确定跨域的路径，并可能从域中选择退出点。
The path computation procedure is outside the scope of this document. A path computation option is specified in [RFC5152], and another option is to use a Path Computation Element (PCE) [RFC4655].
路径计算过程不在本文档的范围内。路径计算选项在[RFC5152]中指定，另一个选项是使用路径计算元素（PCE）[RFC4655]。
4a. In the case of nesting or stitching, either find an existing intra-domain TE LSP to carry the inter-domain TE LSP or signal a new one, depending on local policy.
4a。在嵌套或缝合的情况下，根据本地策略，查找现有的域内TE LSP以承载域间TE LSP或发送新的TE LSP。
In the event of a path computation failure, a PathErr message SHOULD be sent with error code "Routing Problem" using an error value selected according to the reason for computation failure. A domain border node MAY opt to silently discard the Path message in this case as described in Section 8.
在路径计算失败的情况下，应使用根据计算失败原因选择的错误值发送带有错误代码“路由问题”的PathErr消息。如第8节所述，在这种情况下，域边界节点可以选择静默丢弃路径消息。
In the event of the receipt of a PathErr message reporting signaling failure from within the domain or reported from a downstream domain, the domain border node MAY apply crankback procedures as described in Section 3.2. If crankback is not applied, or is exhausted, the border node MUST continue with PathErr processing as described in [RFC3209] and [RFC3473].
如果收到来自域内或下游域的PathErr消息报告信令故障，域边界节点可应用第3.2节所述的回退程序。如果未应用回退或回退已耗尽，则边界节点必须继续执行[RFC3209]和[RFC3473]中所述的路径处理。
In the event of successful processing of a Path or Resv message, the domain border node MUST carry out RRO procedures as described in Section 3.3.
在成功处理路径或Resv消息的情况下，域边界节点必须执行第3.3节所述的RRO程序。
The ERO that a domain border node receives in the Path message was supplied by the ingress node of the TE LSP and may have been updated by other nodes (for example, other domain border nodes) as the Path message was propagated. The content of the ERO depends on several factors including:
域边界节点在路径消息中接收的ERO由TE LSP的入口节点提供，并且在传播路径消息时可能已由其他节点（例如，其他域边界节点）更新。能源监管局的内容取决于几个因素，包括：
- the path computation techniques used, - the degree of TE visibility available to the nodes performing path computation, and - the policy at the nodes creating/modifying the ERO.
- 使用的路径计算技术，-执行路径计算的节点可用的TE可见性程度，以及-创建/修改ERO的节点的策略。
In general, H-LSPs and LSP segments are used between domain border nodes, but there is no restriction on the use of such LSPs to span multiple hops entirely within a domain. Therefore, the discussion that follows may be equally applied to any node within a domain although the term "domain border node" continues to be used for clarity.
通常，在域边界节点之间使用H-LSP和LSP段，但是对于使用此类LSP在域内完全跨越多个跳没有限制。因此，下面的讨论可以同样适用于域内的任何节点，尽管为了清楚起见继续使用术语“域边界节点”。
When a Path message reaches the domain border node, the following rules apply for ERO processing and for further signaling.
当路径消息到达域边界节点时，以下规则适用于ERO处理和进一步信令。
1. If there are any policies related to ERO processing for the LSP, they MUST be applied and corresponding actions MUST be taken. For example, there might be a policy to reject EROs that identify nodes within the domain. In case of inter-domain LSP setup failures due to policy failures related to ERO processing, the node SHOULD issue a PathErr with error code "Policy control failure"/"Inter-domain explicit route rejected", but MAY be configured to silently discard the Path message or to return a different error code for security reasons.
1. 如果存在与LSP的ERO处理相关的任何政策，则必须应用这些政策并采取相应的措施。例如，可能存在拒绝标识域内节点的ERO的策略。如果由于与ERO处理相关的策略失败而导致域间LSP设置失败，则节点应发出错误代码为“策略控制失败”/“域间显式路由被拒绝”的PathErr，但可以配置为以静默方式放弃路径消息或出于安全原因返回不同的错误代码。
2. Section 8.2 of [RFC4206] describes how a node at the edge of a region processes the ERO in the incoming Path message and uses this ERO, to either find an existing H-LSP or signal a new H-LSP using the ERO hops. This process includes adjusting the ERO before sending the Path message to the next hop. These procedures MUST be followed for nesting or stitching of inter-domain TE LSPs.
2. [RFC4206]第8.2节描述了区域边缘的节点如何处理传入路径消息中的ERO，并使用该ERO查找现有的H-LSP或使用ERO跳向新的H-LSP发送信号。此过程包括在将Path消息发送到下一跳之前调整ERO。域间TE LSP的嵌套或缝合必须遵循这些程序。
3. If an ERO subobject identifies a TE link formed by the advertisement of an H-LSP or LSP segment (whether numbered or unnumbered), contiguous signaling MUST NOT be used. The node MUST use either nesting or stitching according to the capabilities of the LSP that forms the TE link, the parameters signaled in the Path message, and local policy. If there is a conflict between the capabilities of the LSP that forms the TE link indicated in the ERO and the parameters on the Path message, the domain border node SHOULD send a PathErr with error code "Routing Problem"/"ERO conflicts with inter-domain signaling method", but MAY be configured to silently discard the Path message or to return a different error code for security reasons.
3. 如果ERO子对象识别由H-LSP或LSP段（无论是否编号）的播发形成的TE链路，则不得使用连续信令。节点必须根据形成TE链路的LSP的能力、路径消息中发送的参数和本地策略使用嵌套或缝合。如果形成ERO中指示的TE链路的LSP的能力与Path消息上的参数之间存在冲突，则域边界节点应发送错误代码为“路由问题”/“ERO与域间信令方法冲突”的PathErr，但出于安全原因，可能会配置为以静默方式放弃路径消息或返回不同的错误代码。
4. An ERO in a Path message received by a domain border node may have a loose hop as the next hop. This may be an IP address or an AS number. In such cases, the ERO MUST be expanded to determine the path to the next hop using some form of path computation that may, itself, generate loose hops.
4. 域边界节点接收的路径消息中的ERO可能有一个松散的跃点作为下一个跃点。这可能是IP地址或AS号码。在这种情况下，必须使用某种形式的路径计算来扩展ERO，以确定到下一跳的路径，该路径计算本身可能会生成松散的跳。
5. In the absence of any ERO subobjects beyond the local domain border node, the LSP egress (the destination encoded in the RSVP Session object) MUST be considered as the next loose hop and rule 4 applied.
5. 在本地域边界节点之外没有任何ERO子对象的情况下，必须将LSP出口（在RSVP会话对象中编码的目的地）视为下一个松散跃点，并应用规则4。
6. In the event of any other failures processing the ERO, a PathErr message SHOULD be sent as described in [RFC3209] or [RFC3473], but a domain border router MAY be configured to silently discard the Path message or to return a different error code for security reasons.
6. 在处理ERO的任何其他故障的情况下，应按照[RFC3209]或[RFC3473]中所述发送PathErr消息，但出于安全原因，可将域边界路由器配置为以静默方式丢弃路径消息或返回不同的错误代码。
When an error occurs during LSP setup, a PathErr message is sent back towards the LSP ingress node to report the problem. If the LSP traverses multiple domains, this PathErr will be seen successively by each domain border node.
在LSP设置过程中发生错误时，将向LSP入口节点发回PathErr消息以报告问题。如果LSP遍历多个域，则每个域边界节点将依次看到该路径。
Domain border nodes MAY apply local policies to restrict the propagation of information about the contents of the domain. For example, a domain border node MAY replace the information in a PathErr message that indicates a specific failure at a specific node with information that reports a more general error with the entire domain. These procedures are similar to those described for the borders of overlay networks in [RFC4208].
域边界节点可以应用本地策略来限制有关域内容的信息的传播。例如，域边界节点可以将指示特定节点上特定故障的PathErr消息中的信息替换为报告整个域中更一般错误的信息。这些程序类似于[RFC4208]中描述的覆盖网络边界的程序。
However:
然而：
- A domain border node MUST NOT suppress the propagation of a PathErr message except to attempt rerouting as described below.
- 域边界节点不得禁止PathErr消息的传播，除非尝试如下所述的重新路由。
- Nodes other than domain border nodes SHOULD NOT modify the contents of a PathErr message.
- 域边界节点以外的节点不应修改PathErr消息的内容。
- Domain border nodes SHOULD NOT modify the contents of a PathErr message unless domain confidentiality is a specific requirement.
- 域边界节点不应修改PathErr消息的内容，除非特定要求域机密性。
Domain border nodes provide an opportunity for crankback rerouting [RFC4920]. On receipt of a PathErr message generated because of an LSP setup failure, a domain border node MAY hold the PathErr and make further attempts to establish the LSP if allowed by local policy and by the parameters signaled on the Path message for the LSP. Such attempts might involve the computation of alternate routes through the domain, or the selection of different downstream domains. If a subsequent attempt is successful, the domain border router MUST discard the held PathErr message, but if all subsequent attempts are unsuccessful, the domain border router MUST send the PathErr upstream toward the ingress node. In this latter case, the domain border router MAY change the information in the PathErr message to provide further crankback details and information aggregation as described in [RFC4920].
域边界节点提供了回退重新路由的机会[RFC4920]。在收到由于LSP设置失败而生成的PathErr消息时，域边界节点可以持有PathErr，并在本地策略和LSP路径消息上指示的参数允许的情况下，进一步尝试建立LSP。这种尝试可能涉及计算通过域的备用路由，或选择不同的下游域。如果后续尝试成功，域边界路由器必须丢弃保留的PathErr消息，但如果所有后续尝试均不成功，域边界路由器必须向入口节点向上游发送PathErr。在后一种情况下，域边界路由器可以更改PathErr消息中的信息，以提供进一步的回退详细信息和信息聚合，如[RFC4920]中所述。
Crankback rerouting MAY also be used to handle the failure of LSPs after they have been established [RFC4920].
回退重路由也可用于处理LSP建立后的故障[RFC4920]。
[RFC3209] defines the RRO as an optional object used for loop detection and for providing information about the hops traversed by LSPs.
[RFC3209]将RRO定义为可选对象，用于循环检测和提供有关LSP穿过的跃点的信息。
As described for overlay networks in [RFC4208], a domain border node MAY filter or modify the information provided in an RRO for confidentiality reasons according to local policy. For example, a series of identifiers of hops within a domain MAY be replaced with the domain identifier (such as the AS number) or be removed entirely leaving just the domain border nodes.
如[RFC4208]中对覆盖网络所述，域边界节点可根据本地策略出于保密原因过滤或修改在RRO中提供的信息。例如，域内跳的一系列标识符可以被域标识符（例如as号码）替换，或者被完全移除，只留下域边界节点。
Note that a domain border router MUST NOT mask its own presence, and MUST include itself in the RRO.
请注意，域边界路由器不得屏蔽其自身的存在，并且必须将其自身包含在RRO中。
Such filtering of RRO information does not hamper the working of the signaling protocol, but the subsequent information loss may render management diagnostic procedures inoperable or at least make them more complicated, requiring the coordination of administrators of multiple domains.
这种对RRO信息的过滤不会妨碍信令协议的工作，但随后的信息丢失可能会使管理诊断程序无法运行，或至少使其更加复杂，需要多个域的管理员进行协调。
Similarly, protocol procedures that depend on the presence of RRO information may become inefficient. For example, the Fast Reroute procedures defined in [RFC4090] use information in the RRO to determine the labels to use and the downstream MP.
类似地，依赖于RRO信息存在的协议过程可能会变得低效。例如，[RFC4090]中定义的快速重路由程序使用RRO中的信息来确定要使用的标签和下游MP。
Notify messages are introduced in [RFC3473]. They may be sent direct rather than hop-by-hop, and so may speed the propagation of error information. If a domain border router is interested in seeing such messages (for example, to enable it to provide protection switching), it is RECOMMENDED that the domain border router update the Notify Request objects in the Path and Resv messages to show its own address following the procedures of [RFC3473].
[RFC3473]中介绍了通知消息。它们可以直接发送，而不是逐跳发送，因此可以加快错误信息的传播。如果域边界路由器有兴趣查看此类消息（例如，为了使其能够提供保护交换），建议域边界路由器按照[RFC3473]的过程更新路径和Resv消息中的Notify Request对象，以显示其自己的地址。
Note that the replacement of a Notify Recipient in the Notify Request object means that some Notify messages (for example, those intended for delivery to the ingress LSR) may need to be examined, processed, and forwarded at domain borders. This is an obvious trade-off issue as the ability to handle notifiable events locally (i.e., within the domain) may or may not outweigh the cost of processing and forwarding Notify messages beyond the domain. Observe that the cost increases linearly with the number of domains in use.
请注意，替换Notify请求对象中的Notify Recipient意味着可能需要在域边界处检查、处理和转发某些Notify消息（例如，打算传递到入口LSR的消息）。这是一个明显的权衡问题，因为本地（即域内）处理应通知事件的能力可能会或可能不会超过域外处理和转发通知消息的成本。请注意，成本随使用的域数线性增加。
Also note that, as described in Section 8, a domain administrator may wish to filter or modify Notify messages that are generated within a domain in order to preserve security or confidentiality of network information. This is most easily achieved if the Notify messages are sent via the domain borders.
还请注意，如第8节所述，域管理员可能希望过滤或修改域内生成的通知消息，以保护网络信息的安全性或机密性。如果通过域边界发送通知消息，则最容易实现这一点。
The following RSVP-TE signaling extensions are defined to enable inter-domain LSP setup.
定义以下RSVP-TE信令扩展以启用域间LSP设置。
In many network environments, there may be a network-wide policy that determines which one of the three inter-domain LSP techniques is used. In these cases, no protocol extensions are required.
在许多网络环境中，可能有一个网络范围的策略来确定使用三种域间LSP技术中的哪一种。在这些情况下，不需要协议扩展。
However, in environments that support more than one technique, an ingress node may wish to constrain the choice made by domain border nodes for each inter-domain TE LSP that it originates.
然而，在支持多种技术的环境中，入口节点可能希望约束域边界节点对其发起的每个域间TE LSP所做的选择。
[RFC4420] defines the LSP_Attributes object that can be used to signal required attributes of an LSP. The Attributes Flags TLV includes Boolean flags that define individual attributes.
[RFC4420]定义LSP_Attributes对象，该对象可用于向LSP的所需属性发送信号。属性标志TLV包括定义单个属性的布尔标志。
This document defines a new bit in the TLV that can be set by the ingress node of an inter-domain TE LSP to restrict the intermediate nodes to using contiguous signaling:
本文档定义了TLV中的一个新位，该位可由域间TE LSP的入口节点设置，以限制中间节点使用连续信令：
Contiguous LSP bit (bit number assignment in Section 9.1)
连续LSP位（第9.1节中的位号分配）
This flag is set by the ingress node that originates a Path message to set up an inter-domain TE LSP if it requires that the contiguous LSP technique is used. This flag bit is only to be used in the Attributes Flags TLV.
如果需要使用连续LSP技术，则该标志由发起路径消息以建立域间TE LSP的入口节点设置。此标志位仅用于属性标志TLV。
When a domain border LSR receives a Path message containing this bit set (one), the node MUST NOT perform stitching or nesting in support of the inter-domain TE LSP being set up. When this bit is clear (zero), a domain border LSR MAY perform stitching or nesting according to local policy.
当域边界LSR接收到包含此位集（一）的路径消息时，节点不得执行缝合或嵌套以支持正在设置的域间TE LSP。当该位清除（零）时，域边界LSR可以根据本地策略执行缝合或嵌套。
This bit MUST NOT be modified by any transit node.
任何传输节点都不能修改该位。
An intermediate node that supports the LSP_Attributes object and the Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, but cannot support contiguous TE LSPs, MUST send a Path Error message with an error code "Routing Problem"/"Contiguous LSP type not supported" if it receives a Path message with this bit set.
支持LSP_Attributes对象和属性标志TLV，并且还识别“连续LSP”位但不支持连续TE LSP的中间节点，如果接收到设置了此位的路径消息，则必须发送带有错误代码“路由问题”/“不支持连续LSP类型”的路径错误消息。
If an intermediate node receiving a Path message with the "Contiguous LSP" bit set in the Flags field of the LSP_Attributes, recognizes the object, the TLV, and the bit and also supports the desired contiguous LSP behavior, then it MUST signal a contiguous LSP. If the node is a domain border node, or if the node expands a loose hop in the ERO, it MUST include an RRO Attributes subobject in the RRO of the corresponding Resv message (if such an object is present) with the "Contiguous LSP" bit set to report its behavior.
如果中间节点接收路径消息时在LSP_属性的标志字段中设置了“连续LSP”位，识别对象、TLV和该位，并且还支持所需的连续LSP行为，则它必须向连续LSP发送信号。如果该节点是域边界节点，或者如果该节点在ERO中扩展一个松散跃点，则它必须在相应Resv消息（如果存在此类对象）的RRO中包含一个RRO Attributes子对象，并设置“连续LSP”位以报告其行为。
Domain border LSRs MUST support and act on the setting of the "Contiguous LSP" flag.
域边界LSR必须支持“连续LSP”标志的设置并对其进行操作。
However, if the intermediate node supports the LSP_Attributes object but does not recognize the Attributes Flags TLV, or supports the TLV but does not recognize this "Contiguous LSP" bit, then it MUST forward the object unmodified.
但是，如果中间节点支持LSP_Attributes对象但不识别Attributes Flags TLV，或者支持TLV但不识别此“连续LSP”位，则它必须转发未修改的对象。
The choice of action by an ingress node that receives a PathErr when requesting the use of a contiguous LSP is out of the scope of this document, but may include the computation of an alternate path.
请求使用连续LSP时接收PathErr的入口节点选择的操作不在本文档的范围内，但可能包括计算备用路径。
The procedures described in Sections 3 and 4 MUST be applied to all inter-domain TE LSPs, including bypass tunnels, detour LSPs [RFC4090], and segment recovery LSPs [RFC4873]. This means that these LSPs will also be subjected to ERO processing, policies, path computation, etc.
第3节和第4节中描述的程序必须适用于所有域间TE LSP，包括旁通隧道、绕行LSP[RFC4090]和段恢复LSP[RFC4873]。这意味着这些LSP也将受到ERO处理、策略、路径计算等的影响。
Note also that the paths for these backup LSPs need to be either pre-configured, computed, and signaled with the protected LSP or computed on-demand at the PLR. Just as with any inter-domain TE LSP, the ERO may comprise strict or loose hops and will depend on the TE visibility of the computation point into the subsequent domain.
还请注意，这些备份LSP的路径需要预先配置、计算并用受保护LSP发送信号，或者在PLR处按需计算。与任何域间TE LSP一样，ERO可以包括严格的跳数或松散的跳数，并且将取决于计算点在后续域中的TE可见性。
If loose hops are present in the path of the backup LSP, ERO expansion will be required at some point along the path: probably at a domain border node. In order that the backup path remains disjoint from the protected LSP(s) the node performing the ERO expansion must
如果备份LSP的路径中存在松散跃点，则需要在路径上的某个点进行ERO扩展：可能在域边界节点。为了使备份路径与受保护的LSP保持不相交，执行ERO扩展的节点必须
be provided with the path of the protected LSPs between the PLR and the MP. This information can be gathered from the RROs of the protected LSPs and is signaled in the DETOUR object for Fast Reroute [RFC4090] and uses route exclusion [RFC4874] for other protection schemes.
在PLR和MP之间提供受保护LSP的路径。该信息可从受保护LSP的RRO收集，并在快速重路由[RFC4090]的绕行对象中发出信号，并使用路由排除[RFC4874]进行其他保护方案。
[RFC4090] describes two methods for local protection for a packet TE LSP in case of link, Shared Risk Link Group (SRLG), or node failure. This section describes how these mechanisms work with the proposed signaling solutions for inter-domain TE LSP setup.
[RFC4090]描述了在链路、共享风险链路组（SRLG）或节点故障情况下对数据包TE LSP进行本地保护的两种方法。本节描述了这些机制如何与域间TE LSP设置的拟议信令解决方案协同工作。
The mode of operation of MPLS-TE Fast Reroute to protect a contiguous, stitched, or nested TE LSP within a domain is identical to the existing procedures described in [RFC4090]. Note that, in the case of nesting or stitching, the end-to-end LSP is automatically protected by the protection operation performed on the H-LSP or stitching segment LSP.
MPLS-TE快速重路由保护域内连续、缝合或嵌套TE LSP的操作模式与[RFC4090]中描述的现有程序相同。注意，在嵌套或缝合的情况下，通过对H-LSP或缝合段LSP执行的保护操作自动保护端到端LSP。
No protocol extensions are required.
不需要协议扩展。
This case arises where two domains are connected by a TE link. In this case, each domain has its own domain border node, and these two nodes are connected by the TE link. An example of this case is where the ASBRs of two ASs are connected by a TE link.
这种情况下，两个域通过TE链路连接。在这种情况下，每个域都有自己的域边界节点，这两个节点通过TE链路连接。这种情况的一个例子是两个ASs的ASBR通过TE链路连接。
A contiguous LSP can be backed up using any PLR and MP, but if the LSP uses stitching or nesting in either of the connected domains, the PLR and MP MUST be domain border nodes for those domains. It will be usual to attempt to use the local (connected by the failed link) domain border nodes as the PLR and MP.
可以使用任何PLR和MP备份连续LSP，但如果LSP在任何连接的域中使用缝合或嵌套，则PLR和MP必须是这些域的域边界节点。通常尝试使用本地（通过故障链路连接）域边界节点作为PLR和MP。
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of backup tunnels must be configured or dynamically computed between the PLR and MP such that they are diversely routed from the protected inter-domain link and the protected inter-domain LSPs.
为了使用MPLS-TE快速重路由保护域间链路，必须在PLR和MP之间配置或动态计算一组备份隧道，以便它们从受保护的域间链路和受保护的域间LSP进行不同路由。
Each protected inter-domain LSP using the protected inter-domain TE link must be assigned to an NHOP bypass tunnel that is diverse from the protected LSP. Such an NHOP bypass tunnel can be selected by analyzing the RROs in the Resv messages of the available bypass
必须将使用受保护域间TE链路的每个受保护域间LSP分配给不同于受保护LSP的NHOP旁路隧道。可以通过分析可用旁路的Resv消息中的RRO来选择这样的NHOP旁路隧道
tunnels and the protected TE LSP. It may be helpful to this process if the extensions defined in [RFC4561] are used to clearly distinguish nodes and links in the RROs.
隧道和受保护的TE LSP。如果使用[RFC4561]中定义的扩展来明确区分RRO中的节点和链接，则可能有助于此过程。
Two border node failure cases exist. If the domain border falls on a link as described in the previous section, the border node at either end of the link may fail. Alternatively, if the border falls on a border node (as is the case with IGP areas), that single border node may fail.
存在两种边界节点故障情况。如果域边界如前一节所述落在链接上，则链接两端的边界节点可能会失败。或者，如果边界落在边界节点上（如IGP区域的情况），则单个边界节点可能会失败。
It can be seen that if stitching or nesting is used, the failed node will be the start or end (or both) of a stitching segment LSP or H-LSP, in which case protection must be provided to the far end of the stitching segment or H-LSP. Thus, where one of these two techniques is in use, the PLR will be the upstream domain entry point in the case of the failure of the domain exit point, and the MP will be the downstream domain exit point in the case of the failure of the domain entry point. Where the domain border falls at a single domain border node, both cases will apply.
可以看出，如果使用缝合或嵌套，故障节点将是缝合段LSP或H-LSP的起点或终点（或两者），在这种情况下，必须为缝合段或H-LSP的远端提供保护。因此，在使用这两种技术中的一种的情况下，在域出口点故障的情况下，PLR将是上游域入口点，并且在域入口点故障的情况下，MP将是下游域出口点。如果域边界位于单个域边界节点，则这两种情况都适用。
If the contiguous LSP mechanism is in use, normal selection of the PLR and MP can be applied, and any node within the domains may be used to fill these roles.
如果使用连续LSP机制，则可以应用PLR和MP的正常选择，并且可以使用域内的任何节点来填充这些角色。
As before, selection of a suitable backup tunnel (in this case, an NNHOP backup) must consider the paths of the backed-up LSPs and the available NNHOP tunnels by examination of their RROs.
如前所述，选择合适的备份隧道（在这种情况下，NNHOP备份）必须考虑备份的LSP和可用的NNHOP隧道的路径，通过检查它们的RROS。
Note that where the PLR is not immediately upstream of the failed node, error propagation time may be delayed unless some mechanism such as [BFD-MPLS] is implemented or unless direct reporting, such as through the GMPLS Notify message [RFC3473], is employed.
注意，如果PLR不是故障节点的直接上游，则错误传播时间可能会延迟，除非实施了诸如[BFD-MPLS]之类的某种机制，或者除非采用了诸如通过GMPLS通知消息[RFC3473]之类的直接报告。
[RFC4873] describes GMPLS-based segment recovery. This allows protection against a span failure, a node failure, or failure over any particular portion of a network used by an LSP.
[RFC4873]描述了基于GMPLS的段恢复。这允许针对跨度故障、节点故障或LSP使用的网络的任何特定部分的故障进行保护。
The domain border failure cases described in Section 5.1 may also occur in GMPLS networks (including packet networks) and can be protected against using segment protection without any additional protocol extensions.
第5.1节中描述的域边界故障情况也可能发生在GMPLS网络（包括分组网络）中，并且可以在不使用任何附加协议扩展的情况下使用段保护进行保护。
Note that if loose hops are used in the construction of the working and protection paths signaled for segment protection, then care is required to keep these paths disjoint. If the paths are signaled incrementally, then route exclusion [RFC4874] may be used to ensure that the paths are disjoint. Otherwise, a coordinated path computation technique such as that offered by cooperating Path Computation Elements [RFC4655] can provide suitable paths.
请注意，如果在为段保护发送信号的工作和保护路径的构造中使用松散跳数，则需要注意保持这些路径不相交。如果路径以增量方式发出信号，则可以使用路由排除[RFC4874]来确保路径不相交。否则，诸如由协作路径计算元件[RFC4655]提供的协调路径计算技术可以提供合适的路径。
Reoptimization of a TE LSP is the process of moving the LSP from the current path to a more preferred path. This involves the determination of the preferred path and make-before-break signaling procedures [RFC3209] to minimize traffic disruption.
TE LSP的再优化是将LSP从当前路径移动到更优选路径的过程。这涉及确定首选路径和先通后断信令程序[RFC3209]，以最大限度地减少交通中断。
Reoptimization of an inter-domain TE LSP may require a new path in more than one domain.
域间TE LSP的重新优化可能需要在多个域中使用新路径。
The nature of the inter-domain LSP setup mechanism defines how reoptimization can be applied. If the LSP is contiguous, then the signaling of the make-before-break process MUST be initiated by the ingress node as defined in [RFC3209]. But if the reoptimization is limited to a change in path within one domain (that is, if there is no change to the domain border nodes) and nesting or stitching is in use, the H-LSP or stitching segment may be independently reoptimized within the domain without impacting the end-to-end LSP.
域间LSP设置机制的性质定义了如何应用重新优化。如果LSP是连续的，则必须由[RFC3209]中定义的入口节点启动先通后断过程的信令。但是，如果重新优化限于一个域内路径的变化（即，如果域边界节点没有变化）并且嵌套或缝合正在使用，则H-LSP或缝合段可以在域内独立地重新优化，而不影响端到端LSP。
In all cases, however, the ingress LSR may wish to exert control and coordination over the reoptimization process. For example, a transit domain may be aware of the potential for reoptimization, but not bother because it is not worried by the level of service being provided across the domain. But the cumulative effect on the end-to-end LSP may cause the head-end to worry and trigger an end-to-end reoptimization request (of course, the transit domain may choose to ignore the request).
然而，在所有情况下，入口LSR可能希望对再优化过程进行控制和协调。例如，传输域可能知道重新优化的可能性，但不会感到麻烦，因为它不担心跨域提供的服务级别。但对端到端LSP的累积效应可能会导致前端担心并触发端到端重新优化请求（当然，传输域可能会选择忽略该请求）。
Another benefit of end-to-end reoptimization over per-domain reoptimization for non-contiguous inter-domain LSPs is that per-domain reoptimization is restricted to preserve the domain entry and exit points (since to do otherwise would break the LSP!). But end-to-end reoptimization is more flexible and can select new domain border LSRs.
对于非连续的域间LSP，端到端重新优化比每域重新优化的另一个好处是，每域重新优化受到限制，以保留域入口和出口点（否则会破坏LSP！）。但端到端重新优化更灵活，可以选择新的域边界LSR。
There may be different cost-benefit analysis considerations between end-to-end reoptimization and per-domain reoptimization. The greater the number of hops involved in the reoptimization, the higher the risk of traffic disruption. The shorter the segment reoptimized, the lower the chance of making a substantial improvement on the quality of the end-to-end LSP. Administrative policies should be applied in this area with care.
端到端再优化和每域再优化之间可能存在不同的成本效益分析考虑因素。重新优化所涉及的跳数越大，交通中断的风险越高。重新优化的段越短，对端到端LSP质量进行实质性改进的机会越低。行政政策在这方面的应用应谨慎。
[RFC4736] describes mechanisms that allow:
[RFC4736]描述了允许以下操作的机制：
- The ingress node to request each node with a loose next hop to re-evaluate the current path in order to search for a more optimal path.
- 入口节点请求具有松散下一跳的每个节点重新评估当前路径，以便搜索更优化的路径。
- A node with a loose next hop to inform the ingress node that a better path exists.
- 具有松散下一跳的节点，用于通知入口节点存在更好的路径。
These mechanisms SHOULD be used for reoptimization of a contiguous inter-domain TE LSP.
这些机制应用于重新优化连续域间TE LSP。
Note that end-to-end reoptimization may involve a non-local modification that might select new entry / exit points. In this case, we can observe that local reoptimization is more easily and flexibly achieved using nesting or stitching. Further, the "locality principle" (i.e., the idea of keeping information only where it is needed) is best achieved using stitching or nesting. That said, a contiguous LSP can easily be modified to take advantage of local reoptimizations (as defined in [RFC4736]) even if this would require the dissemination of information and the invocation of signaling outside the local domain.
请注意，端到端重新优化可能涉及非本地修改，可能会选择新的入口/出口点。在这种情况下，我们可以观察到使用嵌套或缝合更容易和灵活地实现局部重新优化。此外，“局部性原则”（即只在需要的地方保存信息的想法）最好通过缝合或嵌套来实现。也就是说，可以很容易地修改连续LSP以利用本地重新优化（如[RFC4736]中所定义的），即使这需要在本地域之外传播信息和调用信令。
The procedures in this document are backward compatible with existing deployments.
本文档中的过程与现有部署向后兼容。
- Ingress LSRs are not required to support the extensions in this document to provision intra-domain LSPs. The default behavior by transit LSRs that receive a Path message that does not have the "Contiguous LSP" bit set in the Attributes Flags TLV of the LSP_Attributes object or does not even have the object present is to allow all modes of inter-domain TE LSP, so back-level ingress LSRs are able to initiate inter-domain LSPs.
- 入口LSR不需要支持本文档中的扩展来提供域内LSP。接收路径消息的传输LSR的默认行为是，在LSP_Attributes对象的属性标志TLV中没有设置“连续LSP”位，或者甚至没有对象存在，允许域间TE LSP的所有模式，因此后级入口LSR能够启动域间LSP。
- Transit, non-border LSRs are not required to perform any special processing and will pass the LSP_Attributes object onwards unmodified according to the rules of [RFC2205]. Thus, back-level transit LSRs are fully supported.
- 传输、非边界LSR无需执行任何特殊处理，并将根据[RFC2205]的规则向前传递LSP_属性对象，而不进行修改。因此，完全支持后级运输LSR。
- Domain border LSRs will need to be upgraded before inter-domain TE LSPs are allowed. This is because of the need to establish policy, administrative, and security controls before permitting inter-domain LSPs to be signaled across a domain border. Thus, legacy domain border LSRs do not need to be considered.
- 在允许域间TE LSP之前，需要升级域边界LSR。这是因为在允许跨域边界发送域间LSP信号之前，需要建立策略、管理和安全控制。因此，不需要考虑遗留域边界LSR。
The RRO additions in this document are fully backward compatible.
本文档中添加的RRO完全向后兼容。
RSVP does not currently provide for automated key management. [RFC4107] states a requirement for mandatory automated key management under certain situations. There is work starting in the IETF to define improved authentication including automated key management for RSVP. Implementations and deployments of RSVP should pay attention to any capabilities and requirements that are outputs from this ongoing work.
RSVP目前不提供自动密钥管理。[RFC4107]规定了在某些情况下强制自动密钥管理的要求。IETF正在着手定义改进的身份验证，包括RSVP的自动密钥管理。RSVP的实施和部署应注意这项正在进行的工作所产生的任何功能和需求。
A separate document is being prepared to examine the security aspects of RSVP-TE signaling with special reference to multi-domain scenarios [MPLS-SEC]. [RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment.
正在准备一份单独的文件，以检查RSVP-TE信令的安全方面，特别是多域场景[MPLS-SEC]。[RFC4726]概述了MPLS-TE或GMPLS多域环境中的安全要求。
Before electing to utilize inter-domain signaling for MPLS-TE, the administrators of neighboring domains MUST satisfy themselves as to the existence of a suitable trust relationship between the domains. In the absence of such a relationship, the administrators SHOULD decide not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on any inter-domain interfaces.
在选择将域间信令用于MPLS-TE之前，相邻域的管理员必须确保域之间存在适当的信任关系。在没有这种关系的情况下，管理员应决定不部署域间信令，并应在任何域间接口上禁用RSVP-TE。
When signaling an inter-domain RSVP-TE LSP, an operator MAY make use of the security features already defined for RSVP-TE [RFC3209]. This may require some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with FRR, since the MP and PLR should also share the key.
当向域间RSVP-TE LSP发送信号时，运营商可以利用已经为RSVP-TE定义的安全特性[RFC3209]。这可能需要在域之间进行一些协调以共享密钥（请参见[RFC2747]和[RFC3097]），并且需要注意确保密钥的更改足够频繁。注意，如果域边界节点受到FRR保护，这可能涉及额外的同步，因为MP和PLR也应该共享密钥。
For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
对于域间TE LSP，尤其是当它穿越不同的管理域或信任域时，应向操作员提供以下机制（另请参见[RFC4216]）：
1) A way to enforce policies and filters at the domain borders to process the incoming inter-domain TE LSP setup requests (Path messages) based on certain agreed trust and service levels/contracts between domains. Various LSP attributes such as bandwidth, priority, etc. could be part of such a contract.
1) 一种在域边界强制执行策略和筛选器的方法，以根据域之间的某些约定信任和服务级别/契约处理传入的域间TE LSP设置请求（路径消息）。各种LSP属性（如带宽、优先级等）可以是此类合同的一部分。
2) A way for the operator to rate-limit LSP setup requests or error notifications from a particular domain.
2) 操作员对特定域的LSP设置请求或错误通知进行分级限制的一种方法。
3) A mechanism to allow policy-based outbound RSVP message processing at the domain border node, which may involve filtering or modification of certain addresses in RSVP objects and messages.
3) 允许在域边界节点上处理基于策略的出站RSVP消息的机制，这可能涉及过滤或修改RSVP对象和消息中的某些地址。
Additionally, an operator may wish to reduce the signaling interactions between domains to improve security. For example, the operator might not trust the neighboring domain to supply correct or trustable restart information [RFC5063] and might ensure that the availability of restart function is not configured in the Hello message exchange across the domain border. Thus, suitable configuration MUST be provided in an RSVP-TE implementation to enable the operator to control optional protocol features that may be considered a security risk.
此外，运营商可能希望减少域之间的信令交互以提高安全性。例如，操作员可能不信任相邻域提供正确或可信任的重启信息[RFC5063]，并可能确保在跨域边界的Hello消息交换中未配置重启功能的可用性。因此，必须在RSVP-TE实施中提供适当的配置，以使操作员能够控制可能被视为安全风险的可选协议功能。
Some examples of the policies described above are as follows:
上述政策的一些例子如下：
A) An operator may choose to implement some kind of ERO filtering policy on the domain border node to disallow or ignore hops within the domain from being identified in the ERO of an incoming Path message. That is, the policy is that a node outside the domain cannot specify the path of the LSP inside the domain. The domain border LSR can make implement this policy in one of two ways:
A） 运营商可以选择在域边界节点上实施某种ERO过滤策略，以禁止或忽略域内的跃点在传入路径消息的ERO中被识别。也就是说，策略是域外的节点不能指定域内LSP的路径。域边界LSR可以通过以下两种方式之一实施此策略：
- It can reject the Path message.
- 它可以拒绝路径消息。
- It can ignore the hops in the ERO that lie within the domain.
- 它可以忽略域内ERO中的跳数。
B) In order to preserve confidentiality of network topology, an operator may choose to disallow recording of hops within the domain in the RRO or may choose to filter out certain recorded RRO addresses at the domain border node.
B） 为了保护网络拓扑的机密性，运营商可以选择不允许在RRO中记录域内的跃点，或者选择在域边界节点过滤掉某些记录的RRO地址。
C) An operator may require the border node to modify the addresses of certain messages like PathErr or Notify originated from hops within the domain.
C） 操作员可能会要求边界节点修改某些消息的地址，如来自域内跃点的PathErr或Notify。
D) In the event of a path computation failure, an operator may require the border node to silently discard the Path message instead of returning a PathErr. This is because a Path message could be interpreted as a network probe, and a PathErr provides information about the network capabilities and policies.
D） 如果路径计算失败，操作员可能会要求边界节点以静默方式放弃路径消息，而不是返回路径错误。这是因为路径消息可以解释为网络探测，而PathErr提供有关网络功能和策略的信息。
Note that the detailed specification of such policies and their implementation are outside the scope of this document.
请注意，此类政策及其实施的详细规范不在本文件范围内。
Operations, Administration, and Management (OAM) mechanisms including [BFD-MPLS] and [RFC4379] are commonly used to verify the connectivity of end-to-end LSPs and to trace their paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY require that OAM messages are intercepted or modified at domain borders, or are passed transparently across domains. Further discussion of this topic can be found in [INTERAS-PING] and [MPLS-SEC].
包括[BFD-MPLS]和[RFC4379]在内的操作、管理和管理（OAM）机制通常用于验证端到端LSP的连接性并跟踪其路径。在lsp是域间lsp的情况下，此类OAM技术可能要求在域边界处截获或修改OAM消息，或者跨域透明地传递OAM消息。有关此主题的进一步讨论，请参见[INTERAS-PING]和[MPLS-SEC]。
IANA has made the codepoint allocations described in the following sections.
IANA已经完成了以下章节中描述的代码点分配。
A new bit has been allocated from the "Attributes Flags" sub-registry of the "RSVP TE Parameters" registry.
已从“RSVP TE Parameters”注册表的“Attributes Flags”子注册表中分配了一个新位。
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
4 Contiguous LSP Yes No Yes [RFC5150]
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
4 Contiguous LSP Yes No Yes [RFC5150]
New RSVP error codes/values have been allocated from the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP Parameters" registry.
已从“RSVP参数”注册表的“错误代码和全局定义的错误值子代码”子注册表中分配了新的RSVP错误代码/值。
For the existing error code "Policy control failure" (value 2), two new error values have been registered as follows:
对于现有错误代码“策略控制失败”（值2），已注册两个新的错误值，如下所示：
103 = Inter-domain policy failure 104 = Inter-domain explicit route rejected
103=域间策略故障104=域间显式路由被拒绝
For the existing error code "Routing Problem" (value 24), two new error values have been registered as follows:
对于现有错误代码“路由问题”（值24），已注册两个新的错误值，如下所示：
28 = Contiguous LSP type not supported 29 = ERO conflicts with inter-domain signaling method
28=不支持连续LSP类型29=ERO与域间信令方法冲突
The authors would like to acknowledge the input and helpful comments from Kireeti Kompella on various aspects discussed in the document. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
作者希望感谢Kireeti Kompella就文件中讨论的各个方面提出的意见和有益的评论。黛博拉·布伦加德（Deborah Brungard）和迪米特里·帕普迪米特里欧（Dimitri Papdimitriou）提供了详尽的评论。
Thanks to Sam Hartman for detailed discussions of the security considerations.
感谢Sam Hartman对安全考虑的详细讨论。
[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月。
[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月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[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月。
[RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，和JP。Vasseur，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[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月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Ed.，Vasseur，J.-P.，Ed.，和J.Boyle，Ed.，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, June 2006.
[RFC4561]Vasseur，J.-P.，Ed.，Ali，Z.，和S.Sivabalan，“记录路由对象（RRO）节点Id子对象的定义”，RFC 4561，2006年6月。
[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月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化”，RFC 47362006年11月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[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月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，2007年7月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, February 2005.
[BFD-MPLS]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS LSP的BFD”，正在进行的工作，2005年2月。
[INTERAS-PING] Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios", Work in Progress, October 2006.
[INTERAS-PING]Nadeau，T.和G.Swallow，“在AS间和提供商间场景中检测MPLS数据平面故障”，正在进行的工作，2006年10月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J. L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R. Graveman., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2007.
[MPLS-SEC]方，L.，Ed.，贝林格，M.，凯伦，R.，勒鲁，J.L.，张，R.，奈特，P.，斯坦，Y.，比塔，N.，和R.格雷文.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2007年7月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana，A.，Ed.，和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，2007年10月。
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号阿尔西·艾扬加·杜松网络公司，邮编94089
EMail: arthi@juniper.net
EMail: arthi@juniper.net
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA
Jean-Philippe Vasseur Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号-01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.