Internet Engineering Task Force (IETF) V. Beeram, Ed.
Request for Comments: 8370 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 R. Shakir
Google, Inc
D. Pacella
Verizon
T. Saad
Cisco Systems
May 2018
Internet Engineering Task Force (IETF) V. Beeram, Ed.
Request for Comments: 8370 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 R. Shakir
Google, Inc
D. Pacella
Verizon
T. Saad
Cisco Systems
May 2018
Techniques to Improve the Scalability of RSVP-TE Deployments
提高RSVP-TE部署可扩展性的技术
Abstract
摘要
Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.
利用RSVP-TE LSP的网络遇到的实现对所部署LSP数量增长的支持能力有限。
This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.
本文档定义了两种技术，刷新间隔独立RSVP（RI-RSVP）和每对等流控制，它们减少了在标签交换路由器（LSR）中保持RSVP-TE LSP状态所需的处理周期数，从而允许实现支持更大规模的部署。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8370.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8370.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Required Support for RFC 2961 . . . . . . . . . . . . . . . . 4
2.1. Required Functionality from RFC 2961 . . . . . . . . . . 4
2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4
3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5
3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6
3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6
4. Per-Peer Flow Control . . . . . . . . . . . . . . . . . . . . 6
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7
4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Capability Object Values . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Required Support for RFC 2961 . . . . . . . . . . . . . . . . 4
2.1. Required Functionality from RFC 2961 . . . . . . . . . . 4
2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4
3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5
3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6
3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6
4. Per-Peer Flow Control . . . . . . . . . . . . . . . . . . . . 6
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7
4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Capability Object Values . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Networks that utilize RSVP-TE [RFC3209] LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.
使用RSVP-TE[RFC3209]LSP的网络遇到的实现方式在支持已部署LSP数量增长方面能力有限。
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] serves as a powerful toolkit for RSVP-TE implementations to help cover a majority of the concerns about soft-state scaling. However, even with these tools in the toolkit, analysis of existing implementations [RFC5439] indicates that the processing required beyond a certain scale may still cause significant disruption to a Label Switching Router (LSR).
RSVP刷新开销减少程序集[RFC2961]是RSVP-TE实现的强大工具包，有助于解决软状态扩展的大部分问题。然而，即使工具包中有这些工具，对现有实现[RFC5439]的分析表明，超出一定规模所需的处理仍可能对标签交换路由器（LSR）造成重大中断。
This document builds on existing scaling work and analysis and defines protocol extensions to help RSVP-TE deployments push the envelope further on scaling by increasing the threshold above which an LSR struggles to achieve sufficient processing to maintain LSP state.
本文档建立在现有的扩展工作和分析的基础上，并定义了协议扩展，以帮助RSVP-TE部署通过提高LSR难以实现足够处理以保持LSP状态的阈值来进一步推动扩展。
This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that cut down the number of processing cycles required to maintain LSP state. RI-RSVP helps completely eliminate RSVP's reliance on refreshes and refresh timeouts, while Per-Peer Flow Control enables a busy RSVP speaker to apply back pressure to its peer(s). This document defines a unique RSVP Capability [RFC5063] for each technique (support for the CAPABILITY object is a prerequisite for implementing these techniques). Note that the Per-Peer Flow-Control technique requires the RI-RSVP technique as a prerequisite. In order to reap maximum scaling benefits, it is strongly recommended that implementations support both techniques and have them enabled by default. Both techniques are fully backward compatible and can be deployed incrementally.
本文档定义了两种技术，刷新间隔独立RSVP（RI-RSVP）和每个对等流控制，它们减少了维持LSP状态所需的处理周期数。RI-RSVP有助于完全消除RSVP对刷新和刷新超时的依赖，而每个对等流控制使忙碌的RSVP扬声器能够向其对等扬声器施加背压。本文档为每种技术定义了唯一的RSVP能力[RFC5063]（支持能力对象是实现这些技术的先决条件）。请注意，每个对等流控制技术需要RI-RSVP技术作为先决条件。为了获得最大的扩展优势，强烈建议实现支持这两种技术，并在默认情况下启用它们。这两种技术完全向后兼容，并且可以增量部署。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The techniques defined in Sections 3 and 4 are based on proposals made in [RFC2961]. Implementations of these techniques need to support the RSVP messages and procedures defined in [RFC2961] with some minor modifications and alterations to recommended time intervals and iteration counts (see Appendix A for the set of recommended defaults).
第3节和第4节中定义的技术基于[RFC2961]中提出的建议。这些技术的实现需要支持[RFC2961]中定义的RSVP消息和过程，并对建议的时间间隔和迭代计数进行一些小的修改和更改（建议的默认设置见附录A）。
An implementation that supports the techniques discussed in Sections 3 and 4 must support the functionality described in [RFC2961] as follows:
支持第3节和第4节中讨论的技术的实现必须支持[RFC2961]中描述的功能，如下所示：
o It MUST indicate support for RSVP Refresh Overhead Reduction extensions (as specified in Section 2 of [RFC2961]).
o 它必须表明支持RSVP刷新开销减少扩展（如[RFC2961]第2节所述）。
o It MUST support receipt of any RSVP Refresh Overhead Reduction message as defined in [RFC2961].
o 它必须支持接收[RFC2961]中定义的任何RSVP刷新开销减少消息。
o It MUST initiate all RSVP Refresh Overhead Reduction mechanisms as defined in [RFC2961] (including the SRefresh message) with the default behavior being to initiate the mechanisms; however, a configuration override should be offered.
o 它必须启动[RFC2961]（包括SRefresh消息）中定义的所有RSVP刷新开销减少机制，默认行为是启动这些机制；但是，应提供配置覆盖。
o It MUST support reliable delivery of Path/Resv and the corresponding Tear/Err messages (as specified in Section 4 of [RFC2961]).
o 它必须支持路径/Resv和相应的撕裂/错误消息的可靠传递（如[RFC2961]第4节所述）。
o It MUST support retransmission of all unacknowledged RSVP-TE messages using exponential backoff (as specified in Section 6 of [RFC2961]).
o 它必须支持使用指数退避（如[RFC2961]第6节所述）重新传输所有未确认的RSVP-TE消息。
The reliable message delivery mechanism specified in [RFC2961] states that "Nodes receiving a non-out of order [sic] message containing a MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with a MESSAGE_ID_ACK object."
[RFC2961]中规定的可靠消息传递机制规定，“接收包含设置了ACK_所需标志的message_ID对象的非无序[sic]消息的节点应使用message_ID_ACK对象进行响应。”
In an implementation that supports the techniques discussed in Sections 3 and 4, nodes receiving a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set MUST respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can be packed with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects and sent in an Ack message (or piggybacked in any other RSVP message).
在支持第3节和第4节中讨论的技术的实现中，接收包含带有ACK_所需标志集的message_ID对象的非无序消息的节点必须使用message_ID_ACK对象进行响应。此MESSAGE_ID_ACK对象可以与其他MESSAGE_ID_ACK或MESSAGE_ID_NACK对象打包，并在ACK消息中发送（或在任何其他RSVP消息中搭载）。
This improvement to the predictability of the system in terms of reliable message delivery is key for being able to take any action based on a non-receipt of an ACK.
在可靠消息传递方面对系统可预测性的改进对于能够基于未接收到ACK采取任何行动至关重要。
The RSVP protocol relies on periodic refreshes for state synchronization between RSVP neighbors and recovery from lost RSVP messages. It relies on a refresh timeout for stale-state cleanup. The primary motivation behind introducing the notion of Refresh-Interval Independent RSVP (RI-RSVP) is to completely eliminate RSVP's reliance on refreshes and refresh timeouts. This is done by simply increasing the refresh interval to a fairly large value. [RFC2961] and [RFC5439] talk about increasing the value of the refresh interval to provide linear improvement of transmission overhead, but they also point out the degree of functionality that is lost by doing so. This section revisits this notion, but also sets out additional requirements to make sure that there is no loss of functionality incurred by increasing the value of the refresh interval.
RSVP协议依赖于定期刷新来实现RSVP邻居之间的状态同步，并从丢失的RSVP消息中恢复。它依赖于刷新超时来清除陈旧状态。引入与刷新间隔无关的RSVP（RI-RSVP）概念的主要动机是完全消除RSVP对刷新和刷新超时的依赖。这是通过简单地将刷新间隔增加到一个相当大的值来实现的。[RFC2961]和[RFC5439]讨论了增加刷新间隔的值以提供传输开销的线性改善，但他们也指出了这样做所损失的功能程度。本节重新讨论了这一概念，但也提出了其他要求，以确保增加刷新间隔值不会导致功能损失。
An implementation that supports RI-RSVP:
支持RI-RSVP的实现：
o MUST support all of the requirements specified in Section 2.
o 必须支持第2节中规定的所有要求。
o MUST make the default value of the configurable refresh interval (R) be a large value (tens of minutes). A default value of 20 minutes is RECOMMENDED by this document.
o 必须将可配置刷新间隔（R）的默认值设置为大值（几十分钟）。本文档建议默认值为20分钟。
o MUST use a separate shorter refresh interval for refreshing state associated with unacknowledged Path/Resv (uR) messages. A default value of 30 seconds is RECOMMENDED by this document.
o 必须使用单独的较短刷新间隔来刷新与未确认的Path/Resv（uR）消息关联的状态。本文档建议默认值为30秒。
o MUST implement coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. When an RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the speaker MUST act as if all the Path and Resv states learned via the failed signaling adjacency have timed out.
o 必须实现单个LSP的状态与相应RSVP-TE信令邻接状态的耦合。当RSVP-TE扬声器检测到RSVP-TE信令邻接故障时，该扬声器必须表现为通过故障信令邻接学习到的所有路径和Resv状态都已超时。
o MUST make use of the Hello session based on the Node-ID ([RFC3209] [RFC4558]) for detection of RSVP-TE signaling adjacency failures. A default value of 9 seconds is RECOMMENDED by this document for the configurable node hello interval (as opposed to the default value of 5 milliseconds proposed in Section 5.3 of [RFC3209]).
o 必须利用基于节点ID（[RFC3209][RFC4558]）的Hello会话来检测RSVP-TE信令邻接故障。本文件建议可配置节点hello间隔的默认值为9秒（与[RFC3209]第5.3节中建议的默认值5毫秒相反）。
o MUST indicate support for RI-RSVP via the CAPABILITY object [RFC5063] in Hello messages.
o 必须通过Hello消息中的功能对象[RFC5063]指示对RI-RSVP的支持。
An implementation supporting the RI-RSVP technique MUST set a new flag, RI-RSVP Capable, in the CAPABILITY object signaled in Hello messages. The following bit indicates that the sender supports RI-RSVP:
支持RI-RSVP技术的实现必须在Hello消息中发出信号的CAPABILITY对象中设置新标志RI-RSVP Capable。以下位表示发送方支持RI-RSVP：
Bit Number 28 (0x0008) - RI-RSVP Capable (I-bit)
位号28（0x0008）-支持RI-RSVP（I位）
Any node that sets the new I-bit in its CAPABILITY object MUST also set the Refresh-Reduction-Capable bit [RFC2961] in the common header of all RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP functionality MUST NOT be activated for that peer.
在其CAPABILITY对象中设置新I位的任何节点也必须在所有RSVP-TE消息的公共头中设置可刷新减少的位[RFC2961]。如果对等机在功能对象中设置I位，但未设置可刷新减少的位，则不得为该对等机激活RI-RSVP功能。
The RI-RSVP functionality MUST NOT be activated with a peer that does not indicate support for this functionality. Inactivation of the RI-RSVP functionality MUST result in the use of the traditional smaller refresh interval [RFC2205].
RI-RSVP功能不得与不表示支持此功能的对等方一起激活。RI-RSVP功能的停用必须导致使用传统的较小刷新间隔[RFC2205]。
The functionality discussed in this section provides an RSVP speaker with the ability to apply back pressure to its peer(s) to reduce/ eliminate a significant portion of the RSVP-TE control message load.
本节讨论的功能为RSVP扬声器提供了向其对等扬声器施加背压的能力，以减少/消除大部分RSVP-TE控制消息负载。
An implementation that supports Per-Peer Flow Control:
支持每对等流控制的实现：
o MUST support all of the requirements specified in Section 2.
o 必须支持第2节中规定的所有要求。
o MUST support RI-RSVP (Section 3).
o 必须支持RI-RSVP（第3节）。
o MUST treat lack of ACKs from a peer as an indication of a peer's RSVP-TE control-plane congestion. If congestion is detected, the local system MUST throttle RSVP-TE messages to the affected peer. This MUST be done on a per-peer basis. (Per-peer throttling MAY be implemented by a traffic-shaping mechanism that proportionally reduces the RSVP-signaling packet rate as the number of outstanding ACKs increases. When the number of outstanding ACKs decreases, the send rate would be adjusted up again.)
o 必须将缺少来自对等方的ACK视为对等方RSVP-TE控制平面拥塞的指示。如果检测到拥塞，本地系统必须限制发送给受影响对等方的RSVP-TE消息。这必须在每个对等的基础上进行。（每对端节流可通过流量整形机制实现，该机制随着未完成ack的数量增加而成比例地降低RSVP信令分组速率。当未完成ack的数量减少时，发送速率将再次调整。）
o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of [RFC2961] suggests using 3).
o 应使用重试限制（Rl）值7（RFC2961第6.2节建议使用3）。
o SHOULD prioritize Hello messages and messages carrying Acknowledgements over other RSVP messages.
o 应将Hello消息和带有确认的消息优先于其他RSVP消息。
o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that bring up new LSP state) sent to a peer when the local system detects RSVP-TE control-plane congestion in the peer.
o 当本地系统检测到对等机中的RSVP-TE控制平面拥塞时，应将撕裂/错误优先于发送给对等机的触发路径/Resv（显示新LSP状态的消息）。
o MUST indicate support for this technique via the CAPABILITY object [RFC5063] in Hello messages.
o 必须通过Hello消息中的CAPABILITY对象[RFC5063]指示对此技术的支持。
An implementation supporting the Per-Peer Flow-Control technique MUST set a new flag, Per-Peer Flow-Control Capable, in the CAPABILITY object signaled in Hello messages. The following bit indicates that the sender supports Per-Peer Flow Control:
支持每对等流控制技术的实现必须在Hello消息中发出信号的CAPABILITY对象中设置一个新标志，即每对等流控制能力。以下位表示发送方支持每个对等流控制：
Bit Number 27 (0x0010) - Per-Peer Flow-Control Capable (F-bit)
位号27（0x0010）-每个对等流控制功能（F位）
Any node that sets the new F-bit in its CAPABILITY object MUST also set the Refresh-Reduction-Capable bit in the common header of all RSVP-TE messages. If a peer sets the F-bit in the CAPABILITY object but does not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow-Control functionality MUST NOT be activated for that peer.
在其CAPABILITY对象中设置新F位的任何节点也必须在所有RSVP-TE消息的公共头中设置可刷新减少的位。如果对等机在CAPABILITY对象中设置了F位，但未设置可刷新减少的位，则不得为该对等机激活每对等流控制功能。
The Per-Peer Flow-Control functionality MUST NOT be activated with a peer that does not indicate support for this functionality. If a peer hasn't indicated that it is capable of participating in Per-Peer Flow Control, then it SHOULD NOT be assumed that the peer would always acknowledge a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set.
每个对等流控制功能不得与不表示支持此功能的对等流一起激活。如果对等方未表示其能够参与每个对等方的流控制，则不应假定对等方始终确认包含设置了ACK_所需标志的message_ID对象的非故障消息。
IANA maintains the "Capability Object values" subregistry [RFC5063] within the "Resource Reservation Protocol (RSVP) Parameters" registry <http://www.iana.org/assignments/rsvp-parameters>. IANA has assigned two new Capability Object Value bit flags as follows:
IANA在“资源预留协议（RSVP）参数”注册表中维护“能力对象值”子区[RFC5063]<http://www.iana.org/assignments/rsvp-parameters>. IANA分配了两个新的功能对象值位标志，如下所示：
Bit Hex Name Reference
Number Value
------------------------------------------------------------------
28 0x0008 RI-RSVP Capable (I) Section 3
27 0x0010 Per-Peer Flow-Control Capable (F) Section 4
Bit Hex Name Reference
Number Value
------------------------------------------------------------------
28 0x0008 RI-RSVP Capable (I) Section 3
27 0x0010 Per-Peer Flow-Control Capable (F) Section 4
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209], and those that are described in [RFC5920], remain relevant.
本文档不会引入新的安全问题。与原始RSVP协议[RFC2205]和RSVP-TE[RFC3209]以及[RFC5920]中描述的安全注意事项相关的安全注意事项仍然相关。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, <https://www.rfc-editor.org/info/rfc2961>.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 2961，DOI 10.17487/RFC29612001年4月<https://www.rfc-editor.org/info/rfc2961>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, DOI 10.17487/RFC4558, June 2006, <https://www.rfc-editor.org/info/rfc4558>.
[RFC4558]Ali，Z.，Rahman，R.，Prairie，D.，和D.Papadimitriou，“基于节点ID的资源保留协议（RSVP）你好：澄清声明”，RFC 4558，DOI 10.17487/RFC4558，2006年6月<https://www.rfc-editor.org/info/rfc4558>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, <https://www.rfc-editor.org/info/rfc5063>.
[RFC5063]Satyanarayana，A.，Ed.和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，DOI 10.17487/RFC5063，2007年10月<https://www.rfc-editor.org/info/rfc5063>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of Scaling Issues in MPLS-TE Core Networks", RFC 5439, DOI 10.17487/RFC5439, February 2009, <https://www.rfc-editor.org/info/rfc5439>.
[RFC5439]Yasukawa，S.，Farrel，A.，和O.Komolafe，“MPLS-TE核心网络中的扩展问题分析”，RFC 5439，DOI 10.17487/RFC5439，2009年2月<https://www.rfc-editor.org/info/rfc5439>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
a. Refresh Interval (R) - 20 minutes (Section 3): Given that an implementation supporting RI-RSVP doesn't rely on refreshes for state sync between peers, the function of the RSVP refresh interval is analogous to that of IGP refresh interval (the default of which is typically in the order of tens of minutes). Choosing a default of 20 minutes allows the refresh timer to be randomly set to a value in the range [10 minutes (0.5R), 30 minutes (1.5R)].
a. 刷新间隔（R）-20分钟（第3节）：鉴于支持RI-RSVP的实现不依赖于对等方之间状态同步的刷新，RSVP刷新间隔的功能类似于IGP刷新间隔（默认值通常为数十分钟）。选择默认值20分钟可将刷新计时器随机设置为[10分钟（0.5R）、30分钟（1.5R）]范围内的值。
b. Node Hello Interval - 9 seconds (Section 3):
b. 节点Hello间隔-9秒（第3节）：
[RFC3209] defines the hello timeout as 3.5 times the hello interval. Choosing 9 seconds for the node hello interval gives a hello timeout of 3.5 * 9 = 31.5 seconds. This puts the hello timeout value in the vicinity of the IGP hello timeout value.
[RFC3209]将hello超时定义为hello间隔的3.5倍。为节点hello interval选择9秒将给出3.5*9=31.5秒的hello超时。这会将hello超时值置于IGP hello超时值附近。
c. Retry-Limit (Rl) - 7 (Section 4): Choosing 7 as the retry-limit results in an overall rapid retransmit phase of 31.5 seconds. This matches up with the hello timeout of 31.5 seconds.
c. 重试限制（Rl）-7（第4节）：选择7作为重试限制将导致31.5秒的整体快速重传阶段。这与hello超时31.5秒相匹配。
d. Refresh Interval for refreshing state associated with unacknowledged Path/Resv messages (uR) - 30 seconds (Section 3): The recommended refresh interval (R) value of 20 minutes (for an implementation supporting RI-RSVP) cannot be used for refreshing state associated with unacknowledged Path/Resv messages. This document recommends the use of the traditional default refresh interval value of 30 seconds for uR.
d. 刷新与未确认路径/Resv消息关联的状态的刷新间隔（uR）-30秒（第3节）：建议的刷新间隔（R）值20分钟（对于支持RI-RSVP的实现）不能用于刷新与未确认路径/Resv消息关联的状态。本文档建议使用uR的传统默认刷新间隔值30秒。
Acknowledgements
致谢
The authors would like to thank Yakov Rekhter for initiating this work and providing valuable input. They would like to thank Raveendra Torvi and Chandra Ramachandran for participating in the many discussions that led to the techniques discussed in this document. They would also like to thank Adrian Farrel, Lou Berger, and Elwyn Davies for providing detailed review comments and text suggestions.
作者要感谢Yakov Rekhter发起这项工作并提供了宝贵的投入。他们要感谢Ravendra Torvi和Chandra Ramachandran参与了导致本文件中讨论的技术的许多讨论。他们还要感谢Adrian Farrel、Lou Berger和Elwyn Davies提供了详细的审查意见和文本建议。
Contributors
贡献者
Markus Jork Juniper Networks Email: mjork@juniper.net
Markus Jork Juniper Networks电子邮件：mjork@juniper.net
Ebben Aries Juniper Networks Email: exa@juniper.net
Ebben Aries Juniper Networks电子邮件：exa@juniper.net
Authors' Addresses
作者地址
Vishnu Pavan Beeram (editor) Juniper Networks
Vishnu Pavan Beeram（编辑）Juniper Networks
Email: vbeeram@juniper.net
Email: vbeeram@juniper.net
Ina Minei Google, Inc
Ina Minei谷歌公司
Email: inaminei@google.com
Email: inaminei@google.com
Rob Shakir Google, Inc
罗伯夏吉尔谷歌公司
Email: rjs@rob.sh
Email: rjs@rob.sh
Dante Pacella Verizon
Dante Pacella Verizon
Email: dante.j.pacella@verizon.com
Email: dante.j.pacella@verizon.com
Tarek Saad Cisco Systems
塔瑞克萨阿德思科系统公司
Email: tsaad@cisco.com
Email: tsaad@cisco.com