Network Working Group D. Awduche
Request for Comments: 3210 Movaz Networks
Category: Informational A. Hannan
Routingloop
X. Xiao
Photuris
December 2001
Network Working Group D. Awduche
Request for Comments: 3210 Movaz Networks
Category: Informational A. Hannan
Routingloop
X. Xiao
Photuris
December 2001
Applicability Statement for Extensions to RSVP for LSP-Tunnels
LSP隧道RSVP扩展适用性声明
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track.
本备忘录讨论了“LSP隧道RSVP（资源预留协议）扩展”的适用性。它强调了协议的操作原理，并描述了协议设计的网络环境。提供了部署指南，并指出了已知的协议限制。本文件旨在随“LSP隧道RSVP扩展”提交至互联网标准轨道。
Service providers and users have indicated that there is a great need for traffic engineering capabilities in IP networks. These traffic engineering capabilities can be based on Multiprotocol Label Switching (MPLS) and can be implemented on label switching routers (LSRs) from different vendors that interoperate using a common signaling and label distribution protocol. A description of the requirements for traffic engineering in MPLS based IP networks can be found in [2]. There is, therefore, a requirement for an open, non-proprietary, standards based signaling and label distribution protocol for the MPLS traffic engineering application that will allow label switching routers from different vendors to interoperate.
服务提供商和用户已经表示，在IP网络中非常需要流量工程能力。这些流量工程功能可以基于多协议标签交换（MPLS），并且可以在不同供应商的标签交换路由器（LSR）上实现，这些路由器使用通用信令和标签分发协议进行互操作。关于基于MPLS的IP网络中流量工程要求的描述，请参见[2]。因此，MPLS流量工程应用需要一个开放的、非专有的、基于标准的信令和标签分发协议，该协议将允许来自不同供应商的标签交换路由器进行互操作。
The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1] was developed by the IETF MPLS working group to address this requirement. RSVP-TE is a composition of several related proposals
“LSP隧道RSVP扩展”（RSVP-TE）规范[1]由IETF MPLS工作组开发，以满足此要求。RSVP-TE由若干相关提案组成
submitted to the IETF MPLS working group. It contains all the necessary objects, packet formats, and procedures required to establish and maintain explicit label switched paths (LSPs). Explicit LSPs are foundational to the traffic engineering application in MPLS based IP networks. Besides the traffic engineering application, the RSVP-TE specification may have other uses within the Internet.
提交给IETF MPLS工作组。它包含建立和维护显式标签交换路径（LSP）所需的所有必要对象、数据包格式和过程。显式LSP是基于MPLS的IP网络流量工程应用的基础。除了流量工程应用之外，RSVP-TE规范在互联网中可能还有其他用途。
This memo describes the applicability of the RSVP-TE specifications [1]. The protocol's principles of operation are highlighted, the network context for which it was developed is described, guidelines for deployment are offered, and known protocol limitations are indicated.
本备忘录描述了RSVP-TE规范的适用性[1]。重点介绍了协议的工作原理，描述了协议开发的网络环境，提供了部署指南，并指出了已知的协议限制。
This applicability statement concerns only the use of RSVP to set up unicast LSP-tunnels. It is noted that not all of the features described in RFC2205 [3] are required to support the instantiation and maintenance of LSP-tunnels. Aspects related to the support of other features and capabilities of RSVP by an implementation that also supports LSP-tunnels are beyond the scope of this document. However, support of such additional features and capabilities should not introduce new security vulnerabilities in environments that only use RSVP to set up LSP-tunnels.
本适用性声明仅涉及使用RSVP建立单播LSP隧道。需要注意的是，并非RFC2205[3]中描述的所有功能都需要支持LSP隧道的实例化和维护。通过同样支持LSP隧道的实现来支持RSVP的其他特性和功能的相关方面超出了本文档的范围。但是，在仅使用RSVP设置LSP隧道的环境中，对此类附加功能和能力的支持不应引入新的安全漏洞。
This applicability statement does not preclude the use of other signaling and label distribution protocols for the traffic engineering application in MPLS based networks. Service providers are free to deploy whatever signaling protocol that meets their needs.
本适用性声明不排除在基于MPLS的网络中使用其他信令和标签分发协议进行流量工程应用。服务提供商可以自由部署满足其需求的任何信令协议。
In particular, CR-LDP [6] and RSVP-TE [1] are two signaling protocols that perform similar functions in MPLS networks. There is currently no consensus on which protocol is technically superior. Therefore, network administrators should make a choice between the two based upon their needs and particular situation.
具体而言，CR-LDP[6]和RSVP-TE[1]是在MPLS网络中执行类似功能的两种信令协议。目前还没有就哪种协议在技术上更优越达成共识。因此，网络管理员应该根据他们的需要和具体情况在两者之间做出选择。
The RSVP-TE specification extends the original RSVP protocol by giving it new capabilities that support the following functions in an MPLS domain:
RSVP-TE规范扩展了原始RSVP协议，为其提供了支持MPLS域中以下功能的新功能：
(1) downstream-on-demand label distribution (2) instantiation of explicit label switched paths (3) allocation of network resources (e.g., bandwidth) to explicit LSPs (4) rerouting of established LSP-tunnels in a smooth fashion using the concept of make-before-break
(1) 下游按需标签分配（2）显式标签交换路径的实例化（3）将网络资源（例如带宽）分配给显式LSP（4）使用先通后断的概念以平滑的方式重新路由已建立的LSP隧道
(5) tracking of the actual route traversed by an LSP-tunnel (6) diagnostics on LSP-tunnels (7) the concept of nodal abstraction (8) preemption options that are administratively controllable
(5) 跟踪LSP隧道穿过的实际路线（6）对LSP隧道的诊断（7）节点抽象的概念（8）管理上可控的抢占选项
The RSVP-TE specification introduces several new RSVP objects, including the LABEL-REQUEST object, the RECORD-ROUTE object, the LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects. New error messages are defined to provide notification of exception conditions. All of the new objects defined in RSVP-TE are optional with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL objects, which are both mandatory for the establishment of LSP-tunnels.
RSVP-TE规范引入了几个新的RSVP对象，包括LABEL-REQUEST对象、RECORD-ROUTE对象、LABEL对象、EXPLICIT-ROUTE对象和新的会话对象。定义了新的错误消息以提供异常情况通知。就RSVP协议而言，RSVP-TE中定义的所有新对象都是可选的，但LABEL-REQUEST和LABEL对象除外，这两个对象对于LSP隧道的建立都是强制性的。
Two fundamental aspects distinguish the RSVP-TE specification [1] from the original RSVP protocol [3].
RSVP-TE规范[1]与原始RSVP协议[3]有两个基本方面的区别。
The first distinguishing aspect is the fact that the RSVP-TE specification [1] is intended for use by label switching routers (as well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSP-tunnels. The original RSVP specification [3], on the other hand, was intended for use by hosts to request and reserve network resources for micro-flows.
第一个区别方面是，RSVP-TE规范[1]旨在由标签交换路由器（以及主机）使用，以建立和维护LSP隧道，并为此类LSP隧道保留网络资源。另一方面，原始RSVP规范[3]旨在供主机用于请求和保留微流的网络资源。
The second distinguishing aspect is the fact that the RSVP-TE specification generalizes the concept of "RSVP flow." The RSVP-TE specification essentially allows an RSVP session to consist of an arbitrary aggregation of traffic (based on local policies) between the originating node of an LSP-tunnel and the egress node of the tunnel. To be definite, in the original RSVP protocol [3], a session was defined as a data flow with a particular destination and transport layer protocol. In the RSVP-TE specification, however, a session is implicitly defined as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel. The assignment of labels to packets can be based on various criteria, and may even encompass all packets (or subsets thereof) between the endpoints of the LSP-tunnel. Because traffic is aggregated, the number of LSP-tunnels (hence the number of RSVP sessions) does not increase proportionally with the number of flows in the network. Therefore, the RSVP-TE specification [1] addresses a major scaling issue with the original RSVP protocol [3], namely the large amount of system resources that would otherwise be required to manage reservations and maintain state for potentially thousands or even millions of RSVP sessions at the micro-flow granularity.
第二个区别在于，RSVP-TE规范概括了“RSVP流”的概念。RSVP-TE规范基本上允许RSVP会话由LSP隧道的原始节点和隧道的出口节点之间的任意流量聚合（基于本地策略）组成。确切地说，在最初的RSVP协议[3]中，会话被定义为具有特定目的地和传输层协议的数据流。然而，在RSVP-TE规范中，会话被隐式定义为在LSP隧道的发起节点处被分配相同MPLS标签值的分组集。标签对分组的分配可以基于各种标准，并且甚至可以包括LSP隧道的端点之间的所有分组（或其子集）。由于流量是聚合的，因此LSP隧道的数量（因此RSVP会话的数量）不会随着网络中流量的数量成比例增加。因此，RSVP-TE规范[1]解决了原始RSVP协议[3]的一个主要扩展问题，即在微流粒度下管理预订和维护潜在数千甚至数百万RSVP会话状态所需的大量系统资源。
The reader is referred to [1] for a technical description of the RSVP-TE protocol specification.
读者参考[1]了解RSVP-TE协议规范的技术说明。
Use of RSVP-TE is appropriate in contexts where it is useful to establish and maintain explicit label switched paths in an MPLS network. LSP-tunnels may be instantiated for measurement purposes and/or for routing control purposes. They may also be instantiated for other administrative reasons.
RSVP-TE适用于在MPLS网络中建立和维护显式标签交换路径的环境。LSP隧道可为测量目的和/或路由控制目的而实例化。它们也可能因其他管理原因而被实例化。
For the measurement application, an LSP-tunnel can be used to capture various path statistics between its endpoints. This can be accomplished by associating various performance management and fault management functions with an LSP-tunnel, such as packet and byte counters. For example, an LSP-tunnel can be instantiated, with or without bandwidth allocation, solely for the purpose of monitoring traffic flow statistics between two label switching routers.
对于测量应用程序，可以使用LSP隧道捕获其端点之间的各种路径统计信息。这可以通过将各种性能管理和故障管理功能与LSP隧道（如数据包和字节计数器）相关联来实现。例如，可以实例化LSP隧道（有或没有带宽分配），仅用于监视两个标签交换路由器之间的业务流统计。
For the routing control application, LSP-tunnels can be used to forward subsets of traffic through paths that are independent of routes computed by conventional Interior Gateway Protocol (IGP) Shortest Path First (SPF) algorithms. This feature introduces significant flexibility into the routing function and allows policies to be implemented that can result in the performance optimization of operational networks. For example, using LSP-tunnels, traffic can be routed away from congested network resources onto relatively underutilized ones. More generally, load balancing policies can be actualized that increase the effective capacity of the network.
对于路由控制应用，LSP隧道可用于通过独立于传统内部网关协议（IGP）最短路径优先（SPF）算法计算的路由的路径转发流量子集。此功能为路由功能引入了极大的灵活性，并允许实施可导致运行网络性能优化的策略。例如，使用LSP隧道，流量可以从拥挤的网络资源路由到相对未充分利用的网络资源。更一般地说，可以实施负载平衡策略来增加网络的有效容量。
To further enhance the control application, RSVP-TE may be augmented with an ancillary constraint-based routing entity. This entity may compute explicit routes based on certain traffic attributes, while taking network constraints into account. Additionally, IGP link state advertisements may be extended to propagate new topology state information. This information can be used by the constraint-based routing entity to compute feasible routes. Furthermore, the IGP routing algorithm may itself be enhanced to take pre-established LSP-tunnels into consideration while building the routing table. All these augmentations are useful, but not mandatory. In fact, the RSVP-TE specification may be deployed in certain contexts without any of these additional components.
为了进一步增强控制应用，可以使用辅助的基于约束的路由实体来增强RSVP-TE。该实体可以基于某些流量属性计算显式路由，同时考虑网络约束。此外，IGP链路状态广告可以被扩展以传播新的拓扑状态信息。该信息可由基于约束的路由实体用于计算可行路由。此外，IGP路由算法本身可以得到增强，以便在构建路由表时考虑预先建立的LSP隧道。所有这些增强都是有用的，但不是强制性的。事实上，RSVP-TE规范可以在某些上下文中部署，而不需要任何这些附加组件。
The capability to monitor point to point traffic statistics between two routers and the capability to control the forwarding paths of subsets of traffic through a given network topology together make the RSVP-TE specifications applicable and useful for traffic engineering within service provider networks.
监控两个路由器之间的点对点流量统计信息的能力以及通过给定网络拓扑控制流量子集转发路径的能力使RSVP-TE规范适用于服务提供商网络内的流量工程。
These capabilities also make the RSVP-TE applicable, in some contexts, as a component of an MPLS based VPN provisioning framework.
这些功能还使RSVP-TE在某些情况下可作为基于MPLS的VPN配置框架的组件使用。
It is significant that the MPLS architecture [4] states clearly that no single label distribution protocol is assumed for the MPLS technology. Therefore, as noted in the introduction, this applicability statement does not (and should not be construed to) prevent a label switching router from implementing other signaling and label distribution protocols that also support establishment of explicit LSPs and traffic engineering in MPLS networks.
重要的是，MPLS体系结构[4]明确指出，MPLS技术不采用单标签分发协议。因此，如引言中所述，该适用性声明不（也不应被解释为）阻止标签交换路由器实现也支持在MPLS网络中建立显式lsp和流量工程的其他信令和标签分发协议。
When deploying RSVP-TE, there should be well defined administrative policies governing the selection of nodes that will serve as endpoints for LSP-tunnels. Furthermore, when devising a virtual topology for LSP-tunnels, special consideration should be given to the tradeoff between the operational complexity associated with a large number of LSP-tunnels and the control granularity that large numbers of LSP-tunnels allow. Stated otherwise, a large number of LSP-tunnels allows greater control over the distribution of traffic across the network, but increases network operational complexity. In large networks, it may be advisable to start with a simple LSP-tunnel virtual topology and then introduce additional complexity based on observed or anticipated traffic flow patterns.
在部署RSVP-TE时，应该有定义良好的管理策略来管理将用作LSP隧道端点的节点的选择。此外，在为LSP隧道设计虚拟拓扑时，应特别考虑与大量LSP隧道相关的操作复杂性和大量LSP隧道允许的控制粒度之间的权衡。否则，大量LSP隧道允许对网络上的流量分布进行更大的控制，但会增加网络操作的复杂性。在大型网络中，建议从简单的LSP隧道虚拟拓扑开始，然后根据观察到的或预期的交通流模式引入额外的复杂性。
Administrative policies may also guide the amount of bandwidth to be allocated (if any) to each LSP-tunnel. Policies of this type may take into consideration empirical traffic statistics derived from the operational network in addition to other factors.
管理策略还可以指导分配给每个LSP隧道的带宽量（如果有）。除其他因素外，此类政策可考虑从运营网络得出的经验交通统计数据。
The RSVP-TE specification supports only unicast LSP-tunnels. Multicast LSP-tunnels are not supported.
RSVP-TE规范仅支持单播LSP隧道。不支持多播LSP隧道。
The RSVP-TE specification supports only unidirectional LSP-tunnels. Bidirectional LSP-tunnels are not supported.
RSVP-TE规范仅支持单向LSP隧道。不支持双向LSP隧道。
The soft state nature of RSVP remains a source of concern because of the need to generate refresh messages periodically to maintain the state of established LSP-tunnels. This issue is addressed in several proposals that have been submitted to the RSVP working group (see e.g. [5]).
由于需要定期生成刷新消息以维护已建立的LSP隧道的状态，RSVP的软状态性质仍然是一个值得关注的问题。该问题在提交给RSVP工作组的几份提案中得到了解决（见例[5]）。
The applicability of the "Extensions to RSVP for LSP Tunnels" specification has been discussed in this document. The specification introduced several enhancements to the RSVP protocol, which make it
本文件讨论了“LSP隧道RSVP扩展”规范的适用性。该规范对RSVP协议进行了一些增强，使其
applicable in contexts in which the original RSVP protocol would have been inappropriate. One context in which the RSVP-TE specification is particularly applicable is in traffic engineering in MPLS based IP networks.
适用于原始RSVP协议不适用的情况。RSVP-TE规范特别适用的一个上下文是基于MPLS的IP网络中的流量工程。
This document does not introduce new security issues. The RSVP-TE specification adds new opaque objects to RSVP. Therefore, the security considerations pertaining to the original RSVP protocol remain relevant. When deployed in service provider networks, it is mandatory to ensure that only authorized entities are permitted to initiate establishment of LSP-tunnels.
本文档不会引入新的安全问题。RSVP-TE规范向RSVP添加了新的不透明对象。因此，与原始RSVP协议相关的安全注意事项仍然相关。在服务提供商网络中部署时，必须确保仅允许授权实体启动LSP隧道的建立。
The authors gratefully acknowledge the useful comments received from the following individuals during initial review of this memo in the MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow.
作者衷心感谢以下个人在MPLS工作组邮件列表中对本备忘录进行初步审查期间提出的有用意见：Eric Gray、John Renwick和George Swallow。
[1] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
[1] Awduche，D.，Berger，L.，Gan，D.，Li，T.，Swallow，G.和V.Srinivasan，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999.
[2] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[3] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[3] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——版本1，功能规范”，RFC 22052997年9月。
[4] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed Architecture for MPLS", RFC 3031, January 2001.
[4] Rosen，E.，Viswanathan，A.和R.Callon，“MPLS的拟议架构”，RFC 3031，2001年1月。
[5] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[5] Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[6] Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP," Work in Progress.
[6] Jamoussi，B.等人，“使用LDP的基于约束的LSP设置”，正在进行中。
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
Daniel O.Awduche Movaz Networks 7926琼斯支路615室弗吉尼亚州麦克莱恩22102
EMail: awduche@movaz.com
Voice: +1 703-298-5291
EMail: awduche@movaz.com
Voice: +1 703-298-5291
Alan Hannan RoutingLoop 112 Falkirk Court Sunnyvale, CA 94087
阿兰·汉南·罗丁洛普加利福尼亚州桑尼维尔市法尔柯克法院112号，邮编94087
EMail: alan@routingloop.com
Voice: +1 408 666-2326
EMail: alan@routingloop.com
Voice: +1 408 666-2326
XiPeng Xiao Photuris Inc. 2025 Stierlin Ct. Mountain View, CA 94043
西鹏小光科技股份有限公司，2025年，斯特林Ct。加利福尼亚州山景城94043
EMail: xxiao@photuris.com
Voice: +1 650-919-3215
EMail: xxiao@photuris.com
Voice: +1 650-919-3215
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。