Network Working Group J. Manner
Request for Comments: 4094 X. Fu
Category: Informational May 2005
Network Working Group J. Manner
Request for Comments: 4094 X. Fu
Category: Informational May 2005
Analysis of Existing Quality-of-Service Signaling Protocols
现有服务质量信令协议分析
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.
本文档回顾了IP网络的一些现有服务质量（QoS）信令协议。这里的目标是向他们学习，避免常见的误解。此外，我们需要避免在设计和实施这方面的任何新协议时出现错误。
Table of Contents
目录
1. Introduction ....................................................3
2. RSVP and RSVP Extensions ........................................4
2.1. Basic Design ...............................................4
2.1.1. Signaling Model .....................................4
2.1.2. Soft State ..........................................5
2.1.3. Two-Pass Signaling Message Exchanges ................5
2.1.4. Receiver-Based Resource Reservation .................5
2.1.5. Separation of QoS Signaling from Routing ............5
2.2. RSVP Extensions ............................................6
2.2.1. Simple Tunneling ....................................6
2.2.2. IPsec Interface .....................................6
2.2.3. Policy Interface ....................................6
2.2.4. Refresh Reduction ...................................7
2.2.5. RSVP over RSVP ......................................8
2.2.6. IEEE 802-Style LAN Interface ........................8
2.2.7. ATM Interface .......................................9
2.2.8. DiffServ Interface ..................................9
2.2.9. Null Service Type ...................................9
2.2.10. MPLS Traffic Engineering ..........................10
2.2.11. GMPLS and RSVP-TE .................................11
1. Introduction ....................................................3
2. RSVP and RSVP Extensions ........................................4
2.1. Basic Design ...............................................4
2.1.1. Signaling Model .....................................4
2.1.2. Soft State ..........................................5
2.1.3. Two-Pass Signaling Message Exchanges ................5
2.1.4. Receiver-Based Resource Reservation .................5
2.1.5. Separation of QoS Signaling from Routing ............5
2.2. RSVP Extensions ............................................6
2.2.1. Simple Tunneling ....................................6
2.2.2. IPsec Interface .....................................6
2.2.3. Policy Interface ....................................6
2.2.4. Refresh Reduction ...................................7
2.2.5. RSVP over RSVP ......................................8
2.2.6. IEEE 802-Style LAN Interface ........................8
2.2.7. ATM Interface .......................................9
2.2.8. DiffServ Interface ..................................9
2.2.9. Null Service Type ...................................9
2.2.10. MPLS Traffic Engineering ..........................10
2.2.11. GMPLS and RSVP-TE .................................11
2.2.12. GMPLS Operation at UNI and E-NNI Reference
Points ............................................12
2.2.13. MPLS and GMPLS Future Extensions ..................12
2.2.14. ITU-T H.323 Interface .............................13
2.2.15. 3GPP Interface ....................................13
2.3. Extensions for New Deployment Scenarios ...................14
2.4. Conclusion ................................................15
3. RSVP Transport Mechanism Issues ................................16
3.1. Messaging Reliability .....................................16
3.2. Message Packing ...........................................17
3.3. MTU Problem ...............................................17
3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
3.5. What Would Be a Better Alternative? .......................18
4. RSVP Protocol Performance Issues ...............................19
4.1. Processing Overhead .......................................19
4.2. Bandwidth Consumption .....................................20
5. RSVP Security and Mobility .....................................21
5.1. Security ..................................................21
5.2. Mobility Support ..........................................22
6. Other QoS Signaling Proposals ..................................23
6.1. Tenet and ST-II ...........................................23
6.2. YESSIR ....................................................24
6.2.1. Reservation Functionality ..........................24
6.2.2. Conclusion .........................................25
6.3. Boomerang .................................................25
6.3.1. Reservation Functionality ..........................25
6.3.2. Conclusions ........................................26
6.4. INSIGNIA ..................................................26
7. Inter-Domain Signaling .........................................27
7.1. BGRP ......................................................27
7.2. SICAP .....................................................27
7.3. DARIS .....................................................28
8. Security Considerations ........................................30
9. Summary ........................................................30
10. Contributors ..................................................31
11. Acknowledgements ..............................................31
12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
13. Normative References ..........................................38
14. Informative References ........................................38
2.2.12. GMPLS Operation at UNI and E-NNI Reference
Points ............................................12
2.2.13. MPLS and GMPLS Future Extensions ..................12
2.2.14. ITU-T H.323 Interface .............................13
2.2.15. 3GPP Interface ....................................13
2.3. Extensions for New Deployment Scenarios ...................14
2.4. Conclusion ................................................15
3. RSVP Transport Mechanism Issues ................................16
3.1. Messaging Reliability .....................................16
3.2. Message Packing ...........................................17
3.3. MTU Problem ...............................................17
3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
3.5. What Would Be a Better Alternative? .......................18
4. RSVP Protocol Performance Issues ...............................19
4.1. Processing Overhead .......................................19
4.2. Bandwidth Consumption .....................................20
5. RSVP Security and Mobility .....................................21
5.1. Security ..................................................21
5.2. Mobility Support ..........................................22
6. Other QoS Signaling Proposals ..................................23
6.1. Tenet and ST-II ...........................................23
6.2. YESSIR ....................................................24
6.2.1. Reservation Functionality ..........................24
6.2.2. Conclusion .........................................25
6.3. Boomerang .................................................25
6.3.1. Reservation Functionality ..........................25
6.3.2. Conclusions ........................................26
6.4. INSIGNIA ..................................................26
7. Inter-Domain Signaling .........................................27
7.1. BGRP ......................................................27
7.2. SICAP .....................................................27
7.3. DARIS .....................................................28
8. Security Considerations ........................................30
9. Summary ........................................................30
10. Contributors ..................................................31
11. Acknowledgements ..............................................31
12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
13. Normative References ..........................................38
14. Informative References ........................................38
This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.
本文档回顾了IP网络的一些现有QoS信令协议。这里的目标是向他们学习，避免常见的误解。此外，我们需要避免在设计和实施这方面的任何新协议时出现错误。
There have been a number of historic attempts to deliver QoS or generic signaling to the Internet. In the early years, it was believed that multicast would be popular for the majority of communications; thus, both RSVP and earlier ST-II were designed in a way that is multicast-oriented.
有许多历史性的尝试向互联网提供QoS或通用信令。在早期，人们相信多播将在大多数通信中流行；因此，RSVP和早期的ST-II都是以面向多播的方式设计的。
ST-II was developed as a reservation protocol for point-to-multipoint communication. However, since it is sender-initiated, it does not scale with the number of receivers in a multicast group. Its processing is fairly complex. Since every sender needs to set up its own reservation, the total amount of reservation states is large. RSVP was then designed to provide support for multipoint-to-multipoint reservation setup in a more efficient way. However, its complexity, scalability, and ability to meet new requirements have been criticized.
ST-II是作为点对多点通信的保留协议开发的。但是，由于它是由发送方发起的，因此它不随多播组中的接收方数量而扩展。它的处理相当复杂。由于每个发送方都需要设置自己的保留，因此保留状态的总量很大。RSVP被设计为以更有效的方式提供对多点到多点预约设置的支持。然而，它的复杂性、可扩展性和满足新需求的能力受到了批评。
YESSIR (YEt another Sender Session Internet Reservations) [PS98] and Boomerang [FNM+99] are examples of protocols designed after RSVP. Both were meant to be simpler than RSVP. YESSIR is an extension to RTCP, whereas Boomerang is used with ICMP.
YESSIR（另一个发送方会话互联网预订）[PS98]和Boomerang[FNM+99]是在RSVP之后设计的协议示例。两者都比RSVP简单。YESSIR是RTCP的扩展，而Boomerang与ICMP一起使用。
Previously, a lot of work has been targeted at creating a new signaling protocol for resource control. Istvan Cselenyi suggested having a QoSSIG BOF in IETF47, for identifying problems in QoS signaling, but failed to get enough support [URL1]. Some people argued, "in many ways, RSVP improved upon ST-2, and it did start out simpler, but it resulted in a design with complexity and scalability", while others thought that "new knowledge and requirements" made RSVP insufficient. Some concluded that there is no simpler way to handle the same problem than RSVP.
以前，很多工作都是针对创建用于资源控制的新信令协议。Istvan Cselenyi建议在IETF47中使用QoSSIG BOF，以识别QoS信令中的问题，但未能获得足够的支持[URL1]。一些人认为，“在许多方面，RSVP改进了ST-2，并且一开始的确更简单，但它导致了一个具有复杂性和可伸缩性的设计”，而另一些人认为“新知识和需求”使得RSVP不够。一些人得出结论，没有比RSVP更简单的方法来处理相同的问题。
Michael Welzl organized a special session "ABR to the Internet" in SCI 2001, and gathered some inputs for requesting an "ABR to the Internet" BOF in IETF#51, which was intended to introduce explicit rate-feedback-related mechanisms for the Internet (e2e, edge2edge). This failed because of "missing community interest".
Michael Welzl在SCI 2001年组织了一次特别会议“ABR到互联网”，并收集了一些信息，以请求IETF#51中的“ABR到互联网”BOF，旨在为互联网引入明确的速率反馈相关机制（e2e，edge2edge）。由于“缺少社区利益”，这项工作失败了。
OPENSIG [URL2] has been involved in the Internet signaling for years. Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate lightweight Internet signaling. Finally, NSIS BOF was successful, and the NSIS WG was formed.
OPENSIG[URL2]参与互联网信令已有多年。潘平发起了一个SIGLITE[URL3]BOF邮件列表来调查轻量级互联网信令。最后，NSIS转炉获得成功，NSIS工作组成立。
The most mature and original protocols are presented in their own sections, and other QoS signaling protocols are presented in later subsections. The presented protocols are chosen based on relevance to the work within NSIS. The aim is not to review every existing protocol.
最成熟和最原始的协议将在各自的章节中介绍，其他QoS信令协议将在后面的小节中介绍。所提出的协议是根据与NSIS内工作的相关性来选择的。目的不是审查所有现有的议定书。
RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96] has evolved from ST-II to provide end-to-end QoS signaling services for application data streams. Hosts use RSVP to request a specific quality of service (QoS) from the network for particular application flows. Routers use RSVP to deliver QoS requests to all routers along the data path. RSVP also can maintain and refresh states for a requested QoS application flow.
RSVP（资源预留协议）[ZDSZ93][RFC2205][BEBH96]已从ST-II演变为为为应用数据流提供端到端QoS信令服务。主机使用RSVP从网络请求特定应用程序流的特定服务质量（QoS）。路由器使用RSVP向数据路径上的所有路由器发送QoS请求。RSVP还可以维护和刷新请求的QoS应用程序流的状态。
By original design, RSVP fits well into the framework of the Integrated Services (IntServ) [RFC2210] [BEBH96] with certain modularity and scalability.
根据最初的设计，RSVP非常适合集成服务（IntServ）[RFC2210][BEBH96]的框架，具有一定的模块性和可扩展性。
RSVP carries QoS signaling messages through the network, visiting each node along the data path. To make a resource reservation at a node, the RSVP module communicates with two local decision modules, admission control and policy control. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control provides authorization for the QoS request. If either check fails, the RSVP module returns an error notification to the application process that originated the request. If both checks succeed, the RSVP module sets parameters in a packet classifier and packet scheduler to obtain the desired QoS.
RSVP通过网络承载QoS信令消息，沿着数据路径访问每个节点。为了在节点上进行资源预留，RSVP模块与两个本地决策模块（准入控制和策略控制）通信。接纳控制确定节点是否有足够的可用资源来提供请求的QoS。策略控制为QoS请求提供授权。如果任一检查失败，RSVP模块将向发起请求的应用程序进程返回错误通知。如果两个检查都成功，RSVP模块将在数据包分类器和数据包调度器中设置参数，以获得所需的QoS。
The design of RSVP distinguished itself by a number of fundamental ways; particularly, soft state management, two-pass signaling message exchanges, receiver-based resource reservation, and separation of QoS signaling from routing.
RSVP的设计以许多基本方式脱颖而出；特别是，软状态管理、双通道信令消息交换、基于接收器的资源预留以及QoS信令与路由的分离。
The RSVP signaling model is based on a special handling of multicast. The sender of a multicast flow advertises the traffic characteristics periodically to the receivers via "Path" messages. Upon receipt of an advertisement, a receiver may generate a "Resv" message to reserve resources along the flow path from the sender. Receiver reservations may be heterogeneous. To accommodate the multipoint-to-multipoint multicast applications, RSVP was designed to support a vector of reservation attributes called the "style". A style describes whether
RSVP信令模型基于对多播的特殊处理。多播流的发送方通过“路径”消息周期性地向接收方播发业务特性。在接收到广告时，接收器可生成“Resv”消息以沿来自发送者的流路径保留资源。接收方保留可能是异构的。为了适应多点到多点的多播应用，RSVP被设计为支持一个称为“风格”的保留属性向量。样式描述是否
all senders of a multicast group share a single reservation and which receiver is applied. The "Scope" object additionally provides the explicit list of senders.
多播组的所有发送方共享一个保留以及应用哪个接收方。“Scope”对象还提供了发送者的显式列表。
Because the number of receivers in a multicast flow is likely to change, and the flow of delivery paths might change during the life of an application flow, RSVP takes a soft-state approach in its design, creating and removing the protocol states (Path and Resv states) in routers and hosts incrementally over time. RSVP sends periodic refresh messages (Path and Resv) to maintain its states and to recover from occasional lost messages. In the absence of refresh messages, the RSVP states automatically time out and are deleted. States may also be deleted explicitly by PathTear, PathErr with Path_State_Removed flag, or ResvTear Message.
由于多播流中的接收器数量可能会发生变化，并且在应用程序流的生命周期内，传递路径的流可能会发生变化，因此RSVP在其设计中采用软状态方法，随着时间的推移逐渐创建和删除路由器和主机中的协议状态（路径和Resv状态）。RSVP定期发送刷新消息（Path和Resv），以保持其状态并从偶尔丢失的消息中恢复。在没有刷新消息的情况下，RSVP会自动超时并被删除。状态也可以通过PathTear、带有Path_State_Removed标志的PathErr或ResvTear消息显式删除。
The receiver in an application flow is responsible for requesting the desired QoS from the sender. To do this, the receiver issues an RSVP QoS request on behalf of the local application. The request propagates to all routers in reverse direction of the data paths toward the sender. In this process, RSVP requests might be merged, resulting in a protocol that scales well when there are a large number of receivers.
应用程序流中的接收方负责从发送方请求所需的QoS。为此，接收方代表本地应用程序发出RSVP QoS请求。请求以数据路径的相反方向向发送方传播到所有路由器。在这个过程中，RSVP请求可能会被合并，从而形成一个协议，该协议在有大量接收器时可以很好地扩展。
Receiver-initiation is critical for RSVP to set up multicast sessions with a large number of heterogeneous receivers. A receiver initiates a reservation request at a leaf of the multicast distribution tree, traveling toward the sender. Whenever a reservation is found to already exist in a node in the distribution tree, the new request will be merged with the existing reservation. This could result in fewer signaling operations for the RSVP nodes in the multicast tree close to the sender but could introduce a restriction to receiver-initiation.
接收器初始化对于RSVP与大量异构接收器建立多播会话至关重要。接收者在多播分发树的一个叶子上向发送者发出保留请求。每当发现分发树中的节点中已经存在保留时，新请求将与现有保留合并。这可能会导致多播树中靠近发送方的RSVP节点的信令操作减少，但可能会对接收方的启动造成限制。
RSVP messages follow normal IP routing. RSVP is not a routing protocol, but rather is designed to operate with current and future unicast and multicast routing protocols. The routing protocols are responsible for choosing the routes to use to forward packets, and RSVP consults local routing tables to obtain routes. RSVP is responsible only for reservation setup along a data path.
RSVP消息遵循正常的IP路由。RSVP不是一种路由协议，而是设计用于当前和未来的单播和多播路由协议。路由协议负责选择用于转发数据包的路由，RSVP参考本地路由表以获得路由。RSVP仅负责沿数据路径设置预订。
A number of messages and objects have been defined for the protocol. A detailed description is given in [RFC2205].
已经为协议定义了许多消息和对象。[RFC2205]中给出了详细说明。
RSVP [RFC2205] was originally designed to support real-time applications over the Internet. Over the past several years, the demand for multicast-capable real-time teleconferencing, which many people had envisioned to be one of the key Internet applications that could benefit from network-wide deployment of RSVP, has never materialized. Instead, RSVP-TE [RFC3209], a RSVP extension for traffic engineering, has been widely deployed by a large number of network providers to support MPLS applications.
RSVP[RFC2205]最初设计用于支持互联网上的实时应用程序。在过去的几年中，对具有多播功能的实时电话会议的需求从未实现，许多人都认为这是可以从RSVP的全网络部署中获益的关键互联网应用程序之一。相反，RSVP-TE[RFC3209]是用于流量工程的RSVP扩展，已被大量网络提供商广泛部署以支持MPLS应用程序。
There are a large number of protocol extensions based on RSVP. Some provide additional features, such as security and scalability, to the original protocol. Some introduce additional interfaces to other services, such as DiffServ. And some simply define new applications, such as MPLS and GMPLS, that are completely irrelevant from protocol's original intent.
有大量基于RSVP的协议扩展。有些协议为原始协议提供了附加功能，如安全性和可伸缩性。有些引入了其他服务的附加接口，如DiffServ。还有一些简单地定义了新的应用程序，如MPLS和GMPLS，它们与协议的初衷完全无关。
In this section, we list only IETF-based RFCs and a limited set of other organizations' specifications. Informational RFCs (e.g., RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not covered here.
在本节中，我们仅列出基于IETF的RFC和一组有限的其他组织规范。此处不包括信息性RFC（如RFC2998[RFC2998]）和在建工程I-D（如代理）。
[RFC2746] describes an IP tunneling enhancement mechanism that allows RSVP to make reservations across all IP-in-IP tunnels, basically by recursively applying RSVP over the tunnel portion of the path.
[RFC2746]描述了一种IP隧道增强机制，该机制允许RSVP在IP隧道中的所有IP上进行保留，基本上是通过在路径的隧道部分递归应用RSVP。
RSVP can support IPsec on a per-address, per-protocol basis instead of on a per flow basis. [RFC2207] extends RSVP by using the IPsec Security Parameter Index (SPI) in place of the UDP/TCP-like ports. This introduces a new FILTER_SPEC object, which contains the IPsec SPI, and a new SESSION object.
RSVP可以支持基于每个地址、每个协议的IPsec，而不是基于每个流的IPsec。[RFC2207]通过使用IPsec安全参数索引（SPI）代替UDP/TCP类端口来扩展RSVP。这将引入一个新的FILTER_SPEC对象（包含IPsec SPI）和一个新的会话对象。
[RFC2750] specifies the format of POLICY_DATA objects and RSVP's handling of policy events. It introduces objects that are interpreted only by policy-aware nodes (PEPs) that interact with policy decision points (PDPs). Nodes that are unable to interpret the POLICY_DATA objects are called policy-ignorant nodes (PINs). The
[RFC2750]指定策略_数据对象的格式和RSVP对策略事件的处理。它引入了仅由与策略决策点（PDP）交互的策略感知节点（PEP）解释的对象。无法解释策略_数据对象的节点称为策略无知节点（PIN）。这个
content of the POLICY_DATA object itself is protected only between PEPs and therefore provides end-to-middle or middle-to-middle security.
策略_数据对象本身的内容仅在PEP之间受保护，因此提供端到端或中到端安全性。
[RFC2749] specifies the usage of COPS policy services in RSVP environments. [RFC3181] specifies a preemption priority policy element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. [RFC3520] describes how authorization provided by a separate protocol (such as SIP) can be reused with the help of an authorization token within RSVP. The token might therefore contain either the authorized information itself (e.g., QoS parameters) or a reference to those values. The token might be unprotected (which is strongly discouraged) or protected based on symmetric or asymmetric cryptography. Moreover, the document describes how to provide the host with encoded session authorization information as a POLICY_DATA object.
[RFC2749]指定在RSVP环境中使用COPS策略服务。[RFC3181]指定RSVP策略数据对象使用的抢占优先级策略元素（抢占优先级）。[RFC3520]描述了如何借助RSVP中的授权令牌重用单独协议（如SIP）提供的授权。因此，令牌可能包含授权信息本身（例如，QoS参数）或对这些值的引用。令牌可能不受保护（这是非常不鼓励的）或基于对称或非对称加密的保护。此外，本文档描述了如何向主机提供编码的会话授权信息作为策略数据对象。
[RFC2961] describes mechanisms to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost, and refresh state without the transmission of whole refresh messages. It defines the following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects. Three new RSVP message types are defined:
[RFC2961]描述了减少刷新消息处理开销要求、消除RSVP消息丢失时产生的状态同步延迟以及在不传输整个刷新消息的情况下刷新状态的机制。它定义了以下对象：MESSAGE\u ID、MESSAGE\u ID\u ACK、MESSAGE\u ID\u NACK、MESSAGE\u ID LIST、MESSAGE\u ID SRC\u LIST和MESSAGE\u ID MCAST\u LIST对象。定义了三种新的RSVP消息类型：
1) Bundle messages consist of a bundle header followed by a body consisting one or more standard RSVP messages. Bundle messages help in scaling RSVP to reduce processing overhead and bandwidth consumption.
1) 捆绑消息由捆绑头和正文组成，正文由一条或多条标准RSVP消息组成。捆绑消息有助于扩展RSVP以减少处理开销和带宽消耗。
2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. ACK messages are sent between neighboring RSVP nodes to detect message loss and to support reliable RSVP message delivery on a per-hop basis.
2) 确认消息携带一个或多个消息ID确认或消息ID NACK对象。ACK消息在相邻RSVP节点之间发送，以检测消息丢失，并支持基于每跳的可靠RSVP消息传递。
3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects. They correspond to Path and Resv messages that establish the states. Srefresh messages are used to refresh RSVP states without transmitting standard Path or Resv messages.
3) Srefresh消息包含一个或多个MESSAGE_ID LIST、MESSAGE_ID SRC_LIST和MESSAGE_ID MCAST_LIST对象。它们对应于建立状态的Path和Resv消息。Srefresh消息用于刷新RSVP状态，而不传输标准路径或Resv消息。
[RFC3175] allows installation of one or more aggregated reservations in an aggregation region; thus, the number of individual RSVP sessions can be reduced. The protocol type is swapped from RSVP to RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf messages when they enter the aggregation region, and is swapped back when they leave. In addition to a new PathErr code (NEW_AGGREGATE_NEEDED), three new objects are introduced:
[RFC3175]允许在聚合区域中安装一个或多个聚合保留；因此，可以减少单个RSVP会话的数量。协议类型在E2E（标准）Path、PATHTRARE和ResvConf消息进入聚合区域时从RSVP交换到RSVP-E2E-IGNORE，并在它们离开时交换回。除了新的PathErr代码（需要新的聚合）之外，还引入了三个新对象：
1) SESSION object, which contains two values: the IP Address of the aggregate session destination, and the Differentiated Services Code Point (DSCP) that it will use on the E2E data the reservation contains.
1) SESSION对象，它包含两个值：聚合会话目标的IP地址和它将在保留包含的E2E数据上使用的差异化服务代码点（DSCP）。
2) SENDER_TEMPLATE object, which identifies the aggregating router for the aggregate reservation.
2) SENDER_TEMPLATE对象，用于标识聚合保留的聚合路由器。
3) FILTER_SPEC object, which identifies the aggregating router for the aggregate reservation, and is syntactically identical to the SENDER_TEMPLATE object.
3) FILTER_SPEC对象，用于标识聚合保留的聚合路由器，在语法上与SENDER_TEMPLATE对象相同。
From the perspective of RSVP signaling and the handling of data packets in the aggregation region, these cases are equivalent to that of aggregating E2E RSVP reservations. The only difference is that E2E RSVP signaling does not take place and cannot therefore be used as a trigger, so some additional knowledge is required for setting up the aggregate reservation.
从RSVP信令和聚合区域中的数据分组处理的角度来看，这些情况等同于聚合E2E RSVP保留的情况。唯一的区别是E2E RSVP信令不会发生，因此不能用作触发器，因此需要一些额外的知识来设置聚合保留。
[RFC2814] introduces an RSVP LAN_NHOP address object that keeps track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3 addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is used to include the Layer-2 address (L2ADDR) of the previous hop, complementing the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
[RFC2814]引入了一个RSVP LAN_NHOP address对象，当路径消息在两个L3实体（RSVP PHOP和NHOP节点）之间穿过L2域时，该对象跟踪下一个L3跃点。第二层和第三层地址都包含在LAN_NHOP中；RSVP_-HOP_L2对象用于包含前一个跃点的第2层地址（L2ADDR），补充RSVP_-HOP对象（RSVP_-HOP_L3地址）中包含的L3地址信息。
To provide sufficient information for debugging or resource management, RSVP diagnostic messages (DREQ and DREP) are defined in [RFC2745] to collect and report RSVP state information along the path from a receiver to a specific sender.
为了为调试或资源管理提供足够的信息，[RFC2745]中定义了RSVP诊断消息（DREQ和DREP），以收集和报告从接收方到特定发送方的路径上的RSVP状态信息。
[RFC2379] and [RFC2380] define RSVP over ATM implementation guidelines and requirements to interwork with the ATM (Forum) UNI 3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP associated data packets must not be sent on the same virtual circuits (VCs), and that an explicit release of RSVP associated QoS VCs must be performed once the VC for forwarding RSVP control messages terminates. Although a separate control VC is also possible for forwarding RSVP control messages, [RFC2379] recommends creating a best-effort short-cut first (if one does not exist), which can allow setting up RSVP-triggered VCs to use the best-effort end-point. (A short-cut is a point-to-point VC where the two end-points are located in different IP subnets.) For data flows, the subnet senders must establish all QoS VCs, and the RSVP-enabled subnet receiver must be able to accept incoming QoS VCs. RSVP must request that the configurable inactivity timers of VCs be set to "infinite". If it is too complex to do this at the VC receiver, RSVP over ATM implementations are required not to use an inactivity timer to clear any received connections. For dynamic QoS, the replacement of VC should be done gracefully.
[RFC2379]和[RFC2380]定义了与ATM（论坛）UNI 3.x/4.0互通的RSVP over ATM实施指南和要求。[RFC2380]指出，RSVP（控制）消息和RSVP相关数据包不得在同一虚拟电路（VCs）上发送，并且一旦用于转发RSVP控制消息的VC终止，必须执行RSVP相关QoS VCs的显式释放。虽然也可以使用单独的控制VC转发RSVP控制消息，[RFC2379]建议首先创建一条尽力而为的捷径（如果不存在），这可以允许设置RSVP触发的VC使用尽力而为的端点。（捷径是一种点对点VC，其中两个端点位于不同的IP子网中。）对于数据流，子网发送方必须建立所有QoS VCs，并且启用RSVP的子网接收方必须能够接受传入的QoS VCs。RSVP必须请求将VCs的可配置非活动计时器设置为“无限”。如果在VC接收器上执行此操作过于复杂，则要求ATM上的RSVP实现不使用非活动计时器清除任何接收到的连接。对于动态QoS，应该优雅地替换VC。
RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated Services Code Points (DSCPs) in RSVP message objects. If the network element determines that the RSVP request is admissible to the DiffServ network, one or more DSCPs corresponding to the behavior aggregate are determined, and will be carried by the DCLASS Object added to the RESV message upstream toward the RSVP sender.
RFC2996[RFC2996]引入了一个DCLASS对象，以在RSVP消息对象中携带区分服务代码点（DSCP）。如果网元确定区分服务网络可接受RSVP请求，则确定与行为聚合相对应的一个或多个DSCP，并将由添加到RESV消息上游的DCLASS对象携带到RSVP发送方。
For some applications, service parameters are specified by the network, not by the application; e.g., enterprise resource planning (ERP) applications. The Null Service [RFC2997] allows applications to identify themselves to network QoS policy agents using RSVP signaling, but does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). The RSVP sender offers the new service type, 'Null Service Type', in the ADSPEC that is included with the PATH message. A new TSPEC corresponding to the new service type is added to the SENDER_TSPEC. In addition, the RSVP sender will typically include with the PATH message policy objects identifying the user, application and sub-flow, which will be used for network nodes to manage the correspondent traffic flow.
对于某些应用程序，服务参数由网络指定，而不是由应用程序指定；e、 例如，企业资源规划（ERP）应用程序。空服务[RFC2997]允许应用程序使用RSVP信令向网络QoS策略代理标识自己，但不要求它们指定资源需求。网络中的QoS策略代理通过应用适用于应用程序的QoS策略（由网络管理员确定）进行响应。RSVP发送方在PATH消息中包含的ADSPEC中提供了新的服务类型“Null service type”。将与新服务类型对应的新TSPEC添加到发送方\u TSPEC。此外，RSVP发送方通常将包括识别用户、应用程序和子流的路径消息策略对象，这些对象将用于网络节点管理相应的业务流。
RSVP-TE [RFC3209] specifies the core extensions to RSVP for establishing constraint-based explicitly routed LSPs in MPLS networks using RSVP as a signaling protocol. RSVP-TE 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.
RSVP-TE[RFC3209]指定了RSVP的核心扩展，用于在使用RSVP作为信令协议的MPLS网络中建立基于约束的显式路由LSP。RSVP-TE用于标签交换路由器（以及主机）建立和维护LSP隧道，并为此类LSP隧道保留网络资源。
RFC3209 defines a new Hello message (for rapid node failure detection).
RFC3209定义一条新的Hello消息（用于快速节点故障检测）。
RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. Here, a session is the association of LSPs that support the LSP-tunnel. The traffic on an LSP can be classified as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel.
RFC3209还为会话、发送方模板和筛选器规范对象定义了新的C类型（LSP_TUNNEL_IPv4和LSP_TUNNEL_IPv6）。这里，会话是支持LSP隧道的LSP的关联。LSP上的流量可以被分类为在LSP隧道的发起节点处被分配相同MPLS标签值的分组集合。
The following 5 new objects are also defined:
还定义了以下5个新对象：
1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path messages, encapsulating a concatenation of hops that constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined independently of conventional IP routing.
1) 显式路由对象（ERO），它被合并到RSVP路径消息中，封装构成显式路由路径的跳的串联。使用该对象，标签交换RSVP-MPLS流所采用的路径可以独立于传统IP路由预先确定。
2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can create a Path message with a LABEL_REQUEST object. A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages.
2) 标记请求对象。要建立LSP隧道，发送方可以使用LABEL_请求对象创建路径消息。发送LABEL_请求对象的节点必须准备好接受并正确处理相应Resv消息中的LABEL对象。
3) LABEL object. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel.
3) 标签对象。接收包含标签对象的Resv消息的每个节点将该标签用于与此LSP隧道关联的传出流量。
4) SESSION_ATTRIBUTE object, which can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and holding priorities, resource affinities, and local-protection, are also included in this object.
4) 会话\属性对象，可添加到路径消息中，以帮助会话识别和诊断。此对象中还包括其他控制信息，例如设置和保持优先级、资源亲缘关系和本地保护。
5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in both Path and Resv messages. It is used to collect detailed path information and is useful for loop detection and for diagnostics.
5) 记录路由对象（RRO）。记录路由对象可能同时出现在Path和Resv消息中。它用于收集详细的路径信息，并用于环路检测和诊断。
Section 5 of [RFC3270] further specifies the extensions to RSVP to establish LSPs supporting DiffServ in MPLS networks, introducing a new DIFFSERV Object (applicable in the Path messages), and using pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
[RFC3270]第5节进一步规定了RSVP的扩展，以建立支持MPLS网络中区分服务的LSP，引入新的区分服务对象（适用于路径消息），并使用预配置或信号化的“EXP<-->PHB映射”（例如[RFC3270]）。
RSVP-TE provides a way to indicate an unnumbered link in its Explicit Route and Record Route Objects through [RFC3477]. This specifies the following extensions:
RSVP-TE提供了一种在显式路由中指示未编号链路的方法，并通过[RFC3477]记录路由对象。这将指定以下扩展：
- An Unnumbered Interface ID Subobject, which is a subobject of the Explicit Route Object (ERO) used to specify unnumbered links.
- 未编号的接口ID子对象，它是用于指定未编号链接的显式路由对象（ERO）的子对象。
- An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to form or use an identifier for an unnumbered Forwarding Adjacency.
- LSP_TUNNEL_INTERFACE_ID对象，用于允许相邻LSR形成或使用无编号转发邻接的标识符。
- A new subobject of the Record Route Object, used to record that the LSP path traversed an unnumbered link.
- 记录路由对象的新子对象，用于记录LSP路径穿过未编号的链路。
GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the provisioning of data-paths within networks supporting a variety of switching types including packet and cell switching networks, layer two networks, TDM networks, and photonic networks.
GMPLS RSVP-TE[RFC3473]是RSVP-TE的扩展。它能够在支持多种交换类型的网络中提供数据路径，包括分组和小区交换网络、第二层网络、TDM网络和光子网络。
It defines the new Notify message (for general event notification), which may contain notifications being sent, with respect to each listed LSP, both upstream and downstream. Notify messages can be used for expedited notification of failures and other events to nodes responsible for restoring failed LSPs. A Notify message is sent without the router alert option.
它定义了新的Notify消息（用于一般事件通知），其中可能包含针对每个列出的LSP（上游和下游）发送的通知。Notify消息可用于将故障和其他事件快速通知负责恢复故障LSP的节点。在不使用路由器警报选项的情况下发送通知消息。
A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS:
GMPLS RSVP-TE中定义了许多新的RSVP-TE（子）对象，用于MPLS的一般用途：
- a Generalized Label Request Object;
- 广义标签请求对象；
- a Generalized Label Object;
- 广义标签对象；
- a Suggested Label Object;
- 建议的标签对象；
- a Label Set Object (to restrict label choice);
- 标签集对象（用于限制标签选择）；
- an Upstream_Label object (to support bidirectional LSPs);
- 上游_标签对象（支持双向lsp）；
- a Label ERO subobject;
- 标签子对象；
- IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in out-of-band signaling or in bundled links);
- IF_ID RSVP_HOP对象（IPv4&IPv6；用于标识带外信令或捆绑链路中的接口）；
- IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in out-of-band signaling or in bundled links);
- IF_ID ERROR_SPEC objects（IPv4&IPv6；用于标识带外信令或捆绑链路中的接口）；
- an Acceptable Label Set object (to support negotiation of label values in particular for bidirectional LSPs)
- 可接受的标签集对象（支持标签值协商，尤其是双向LSP）
- a Notify Request object (may be inserted in a Path or Resv message to indicate where a notification of LSP failure is to be sent)
- Notify请求对象（可插入路径或Resv消息中，以指示LSP失败通知的发送位置）
- a Restart_Cap Object (used on Hello messages to identify recovery capabilities)
- Restart_Cap对象（用于Hello消息以识别恢复功能）
- an Admin Status Object (to notify each node along the path of the status of the LSP, and to control that state).
- 管理状态对象（用于通知路径上的每个节点LSP的状态，并控制该状态）。
The ITU-T defines network reference points that separate administrative or operational parts of the network. The reference points are designated as:
ITU-T定义了网络参考点，用于分离网络的管理或操作部分。参考点指定为：
- User to Network Interfaces (UNIs) if they lie between the user or user network and the core network, or
- 用户到网络接口（UNI），如果它们位于用户或用户网络与核心网络之间，或
- External Network to Network Interfaces (E-NNIs) if they lie between peer networks, network domains, or subnetworks.
- 外部网络到网络接口（E-NNI），如果它们位于对等网络、网络域或子网络之间。
GMPLS is applicable to the UNI and E-NNI without further modification, and no new messages, objects, or C-Types are required. See [OVERLAY].
GMPLS适用于UNI和E-NNI，无需进一步修改，并且不需要新的消息、对象或C类型。见[叠加]。
At the time of writing, MPLS and GMPLS are being extended by the MPLS and CCAMP Working Groups to support additional sophisticated functions. This will inevitably lead to the introduction of new C-Types for existing objects, and to the requirement for new objects (CNums). It is possible that new messages will also be introduced.
在撰写本文时，MPLS和CCAMP工作组正在扩展MPLS和GMPLS，以支持其他复杂功能。这将不可避免地导致为现有对象引入新的C类型，以及对新对象（CNUM）的需求。可能还会引入新的消息。
Some of the key features and functions being introduced include the following:
正在介绍的一些关键特性和功能包括：
- Protection and restoration. Features will be developed to provide - end-to-end protection - segment protection - various protection schemes (1+1, 1:1, 1:n) - support of extra traffic on backup LSPs - Diverse path establishment for protection and load sharing. - Establishment of point-to-multipoint paths. - Inter-area and inter-AS path establishment with - explicit path control - bandwidth reservation - path diversity - Support for the requirements of Automatic Switched Optical Network (ASON) signaling as defined by the ITU-T, including call and connection separation. - Crankback during LSP setup.
- 保护和恢复。将开发功能以提供-端到端保护-段保护-各种保护方案（1+1、1:1、1:n）-支持备份LSP上的额外流量-建立用于保护和负载共享的不同路径。-建立点对多点路径。-具有显式路径控制的区域间和AS间路径建立-带宽保留-路径分集-支持ITU-T定义的自动交换光网络（ASON）信令要求，包括呼叫和连接分离。-LSP设置期间的回退。
ITU-T H.323 ([H.323]) recommends the IntServ resource reservation procedure using RSVP. The information as to whether an endpoint supports RSVP should be conveyed during the H.245 [H.245] capability exchange phase, by setting appropriate qOSMode fields. If both endpoints are RSVP-capable, when opening an H.245 logical channel, a receiver port ID should be conveyed to the sender by the openLogicalChannelAck message. Only after that can a "Path - Resv - ResvConf" process take place. The timer of waiting for ResvConf message will be set by the endpoint. If this timer expires or RSVP reservation fails at any point during an H.323 call, the action is up to the vendor. Once a ResvConf message is sent or received, the endpoints should stop reservation timers and resume with the H.323 call procedures. Only explicit release of reservations are supported in [H.323]. Before sending a closeLogicalChannel message for a stream, a sender should send a PathTear message if an RSVP session has been previous created for that stream. After receiving a closeLogicalChannel, a receiver should send a ResvTear similarly. Only the FF style is supported, even for point-to-multipoint calls.
ITU-T H.323（[H.323]）推荐使用RSVP的IntServ资源预留过程。关于端点是否支持RSVP的信息应在H.245[H.245]能力交换阶段通过设置适当的qOSMode字段来传递。如果两个端点都支持RSVP，则在打开H.245逻辑通道时，应通过OpenLogicalChannel确认消息将接收器端口ID传送给发送方。只有在这之后，才能进行“Path-Resv-ResvConf”过程。等待ResvConf消息的计时器将由端点设置。如果在H.323呼叫期间，该计时器过期或RSVP预约在任何时候失败，则由供应商决定。一旦发送或接收到ResvConf消息，端点应停止保留计时器并继续执行H.323呼叫过程。[H.323]中只支持明确释放保留。在为流发送closeLogicalChannel消息之前，如果先前已为该流创建了RSVP会话，则发送方应发送PathTear消息。在接收到closeLogicalChannel后，接收器应发送一个类似的ResvTear。仅支持FF样式，即使对于点对多点调用也是如此。
Third Generation Partnership Project (3GPP) TS 23.207 ([3GPP-TS23207]) specifies the QoS signaling procedure with policy control within the Universal Mobile Telecommunications System (UMTS) end-to-end QoS architecture. When using RSVP, the signaling source and/or destination are the User Equipments (UEs, devices that allow users access to network services) that locate in the Mobile
第三代合作伙伴计划（3GPP）TS 23.207（[3GPP-TS23207]）规定了通用移动通信系统（UMTS）端到端QoS架构内具有策略控制的QoS信令过程。当使用RSVP时，信令源和/或目的地是位于移动设备中的用户设备（ue，允许用户访问网络服务的设备）
Originating (MO) side and the Mobile Terminating (MT) side. An RSVP signaling process can either trigger or be triggered by the (COPS) PDP Context establishment/modification process. The operation of refreshing states is not specified in [3GPP-TS23207]. If a bidirectional reservation is needed, the RSVP signaling exchange must be performed twice between the end-points. The authorization token and flow identifier(s) in a policy data object should be included in the RSVP messages sent by the UE, if the token is available in the UE. When both RSVP and Service-based Local Policy are used, the Gateway GPRS Support Node (GGSN, the access point of the network) should use the policy information to decide whether to accept and forward Path/Resv messages.
始发（MO）侧和移动终端（MT）侧。RSVP信令过程可以触发，也可以由（COPS）PDP上下文建立/修改过程触发。[3GPP-TS23207]中未规定刷新状态的操作。如果需要双向预留，则必须在端点之间执行两次RSVP信令交换。如果令牌在UE中可用，则策略数据对象中的授权令牌和流标识符应包括在UE发送的RSVP消息中。当同时使用RSVP和基于服务的本地策略时，网关GPRS支持节点（GGSN，网络的接入点）应使用策略信息来决定是否接受和转发Path/Resv消息。
As a well-acknowledged protocol in the Internet, RSVP is expected more and more to provide a more generic service for various signaling applications. However, RSVP messages were designed in a way to support end-to-end QoS signaling optimally. To meet the increasing demand that a signaling protocol also operate in host-to-edge and edge-to-edge ways, and that it serve for some other signaling purposes in addition to end-to-end QoS signaling, RSVP needs to be made more flexible and applicable for more generic signaling.
RSVP协议作为Internet上公认的协议，越来越多地被期望为各种信令应用提供更通用的服务。然而，RSVP消息的设计方式是以最佳方式支持端到端QoS信令。为了满足日益增长的需求，即信令协议也以主机到边缘和边缘到边缘的方式运行，并且除了端到端QoS信令之外，它还用于其他一些信令目的，RSVP需要变得更灵活，并适用于更通用的信令。
RSVP proxies [BEGD02] extend RSVP by originating or receiving the RSVP message on behalf of the end node(s), so that applications may still benefit from reservations that are not truly end-to-end. However, there are certainly scenarios where an application would want to explicitly convey its non-QoS purposed (as well as QoS) data from a host into the network, or from an ingress node to an egress node of an administrative domain. It must do so without burdening the network with excess messaging overhead. Typical examples are an end host desiring a firewall service from its provider's network and MPLS label setup within an MPLS domain.
RSVP代理[BEGD02]通过代表终端节点发起或接收RSVP消息来扩展RSVP，因此应用程序仍然可以受益于并非真正端到端的保留。然而，在某些情况下，应用程序肯定希望将其非QoS目的（以及QoS）数据从主机显式传输到网络，或者从入口节点传输到管理域的出口节点。它必须做到这一点，而不会给网络带来过多的消息传递开销。典型的例子是希望从其提供商的网络获得防火墙服务的终端主机，以及MPLS域内的MPLS标签设置。
RSVP requires support from network routers and user space applications. Domains not supporting RSVP are traversed transparently. Unfortunately, like other IP options, RSVP messages implemented by way of IP alert option may be dropped by some routers [FJ02]. Although applications need to be built with RSVP libraries, one article presents a mechanism that would allow any host to benefit from RSVP mechanisms without applications' awareness [MHS02].
RSVP requires support from network routers and user space applications. Domains not supporting RSVP are traversed transparently. Unfortunately, like other IP options, RSVP messages implemented by way of IP alert option may be dropped by some routers [FJ02]. Although applications need to be built with RSVP libraries, one article presents a mechanism that would allow any host to benefit from RSVP mechanisms without applications' awareness [MHS02].translate error, please retry
A somewhat similar deployment benefit can be gained from the Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the concept of local RSVP-based reservation that alone can be used to trigger reservation within an access network. In those cases, an end-host may request QoS from its own access network without the
从本地化的RSVP（LRSVP）[JR03][MSK+04]可以获得类似的部署好处。这些文件提出了基于本地RSVP的预留的概念，仅此概念就可用于触发接入网络内的预留。在这些情况下，终端主机可以从其自己的接入网络请求QoS，而无需
cooperation of a correspondent node outside the access network. This would be especially helpful when the correspondent node is unaware of RSVP. A proxy node responds to the messages sent by the end host and enables both upstream and downstream reservations. Furthermore, the scheme allows for faster reservation repairs following a handover by triggering the proxy to assist in an RSVP local repair.
接入网外部的对应节点的协作。当对应节点不知道RSVP时，这将特别有用。代理节点响应终端主机发送的消息，并启用上游和下游保留。此外，该方案通过触发代理以协助RSVP本地修复，允许在切换后更快地进行预约修复。
Still, in end-hosts that are low in processing power and functionality, having an RSVP daemon run and take care of the signaling may introduce unnecessary overhead. One article [Kars01] proposes to create a remote API so that the daemon would in fact run on the end-host's default router and the end-host application would send its requests to that daemon.
尽管如此，处理能力和功能都很低的终端主机，运行RSVP守护进程并处理信令可能会带来不必要的开销。一篇文章[Kars01]建议创建一个远程API，这样守护进程实际上将在终端主机的默认路由器上运行，并且终端主机应用程序将向该守护进程发送其请求。
Another potential problem lies in the limited size of signaled data due to the limitation of message size. An RSVP message must fit entirely into a single non-fragmented IP datagram. Bundle messages [RFC2961] can aggregate multiple RSVP messages within a single PDU, but they still only occupy one IP datagram (i.e., approximately 64K). If it exceeds the MTU, the datagram is fragmented by IP and reassembled at the recipient node.
另一个潜在问题在于，由于消息大小的限制，信号数据的大小有限。RSVP消息必须完全适合单个非碎片化IP数据报。捆绑消息[RFC2961]可以在单个PDU内聚合多个RSVP消息，但它们仍然只占用一个IP数据报（即约64K）。如果超过MTU，数据报将被IP分段并在接收方节点重新组装。
A good signaling protocol should be transparent to the applications. RSVP has proven to be a very well designed protocol. However, it has a number of fundamental protocol design issues that require more careful re-evaluation.
一个好的信令协议应该对应用程序透明。RSVP已被证明是一个设计良好的协议。然而，它有一些基本的协议设计问题，需要更仔细的重新评估。
The design of RSVP was originally targeted at multicast applications. The result has been that the message processing within nodes is somewhat heavy, mainly due to flow merging. Still, merging rules should not appear in the specification as they are QoS-specific.
RSVP的设计最初是针对多播应用的。结果是节点内的消息处理有些繁重，主要是由于流合并。不过，合并规则不应该出现在规范中，因为它们是特定于QoS的。
RSVP has a comprehensive set of filtering styles, including Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE), and is not tied to certain QoS objects. (RSVP is not tied to IntServ Guaranteed Service/Controlled Load (GS/CL) specifications.) Objects were designed to be modular, but Xspecs (TSPEC, etc.) are more or less QoS-specific and should be more generalized; there is no clear layering/separation between the signaled data and signaling protocol.
RSVP有一套全面的过滤样式，包括通配符过滤器（WF）、固定过滤器（FF）和共享显式（SE），并且不与某些QoS对象绑定。（RSVP与IntServ保证的服务/控制负载（GS/CL）规范无关。）对象设计为模块化，但XSpec（TSPEC等）或多或少是QoS特定的，应该更通用；信号数据和信号协议之间没有明确的分层/分离。
RSVP uses a soft state mechanism to maintain states and allows each node to define its own refresh timer. The protocol is also independent of underlying routing protocols. Still, in mobile networks the movement of the mobile nodes may not properly trigger a reservation refresh for the new path, and therefore a mobile node may be left without a reservation up to the length of the refresh timer.
RSVP使用软状态机制来维护状态，并允许每个节点定义自己的刷新计时器。该协议也独立于底层路由协议。然而，在移动网络中，移动节点的移动可能不会正确地触发对新路径的保留刷新，因此移动节点可能在刷新定时器的长度内没有保留。
Furthermore, RSVP does not work properly with changing end-point identifiers; that is, if one of the IP addresses of a mobile node changes, the filters may not be able to identify the flow that had a reservation.
此外，RSVP不能在改变端点标识符时正常工作；也就是说，如果移动节点的IP地址之一改变，则过滤器可能无法识别具有保留的流。
From the security point of view, RSVP does provide the basic building blocks for deploying the protocol in various environments to protect its messages from forgery and modification. Hop-by-hop protection is provided. However, the current RSVP security mechanism does not provide non-repudiation and protection against message deletion; the two-way peer authentication and key management procedures are still missing.
从安全角度来看，RSVP确实提供了在各种环境中部署协议的基本构建块，以保护其消息不被伪造和修改。提供逐跳保护。但是，当前的RSVP安全机制不提供不可否认性和防止消息删除的保护；双向对等身份验证和密钥管理程序仍然缺失。
Finally, since the publication of the RSVP standard, tens of extensions have emerged that allow for much wider deployment than RSVP was originally designed for -- for instance, the Subnet Bandwidth Manager, the NULL service type, aggregation, operation over tunneling, and MPLS, as well as diagnostic messages.
最后，自RSVP标准发布以来，出现了数十个扩展，它们允许比RSVP最初设计的部署范围更广的部署—例如，子网带宽管理器、空服务类型、聚合、隧道操作和MPLS，以及诊断消息。
Domains not supporting RSVP are traversed transparently by default. Unfortunately, like other IP options, RSVP messages implemented by way of IP alert option may be dropped by some routers. Also, the maximal size of RSVP message is limited.
默认情况下，不支持RSVP的域是透明的。不幸的是，与其他IP选项一样，通过IP警报选项实现的RSVP消息可能会被某些路由器丢弃。此外，RSVP消息的最大大小也受到限制。
The transport mechanisms, performance, security, and mobility issues are detailed in the following sections.
以下各节详细介绍了传输机制、性能、安全性和移动性问题。
RSVP messages are defined as a new IP protocol (that is, a new ptype in the IP header). RSVP Path messages must be delivered end-to-end. For the transit routers to intercept the Path messages, a new IP Router Alert option [RFC2113] was introduced. This design is simple to implement and efficient to run. As shown from the experiments in [PS00], with minor kernel changes IP option processing introduces very little overhead on a Free BSD box.
RSVP消息被定义为一个新的IP协议（即，IP报头中的一个新ptype）。RSVP路径消息必须端到端传递。为了让中转路由器拦截路径消息，引入了一个新的IP路由器警报选项[RFC2113]。该设计实现简单，运行效率高。正如[PS00]中的实验所示，在内核发生微小变化的情况下，IP选项处理在一个空闲的BSD盒上引入的开销非常小。
However, RSVP does not have a good message delivery mechanism. If a message is lost on the wire, the next re-transmit cycle by the network would be one soft-state refresh interval later. By default, a soft-state refresh interval is 30 seconds.
但是，RSVP没有良好的消息传递机制。如果消息在线路上丢失，网络的下一个重新传输周期将是稍后的一个软状态刷新间隔。默认情况下，软状态刷新间隔为30秒。
To overcome this problem, [PS97] introduced a staged refresh timer mechanism, which has been defined as a RSVP extension in [RFC2961]. The staged refresh timer mechanism retransmits RSVP messages until the receiving node acknowledges. It can address the reliability problem in RSVP.
为了克服这个问题，[PS97]引入了一种分段刷新计时器机制，该机制在[RFC2961]中定义为RSVP扩展。分段刷新计时器机制重新传输RSVP消息，直到接收节点确认。它可以解决RSVP中的可靠性问题。
However, during the mechanism's implementation, a lot of effort had to be spent on per-session timer maintenance, message retransmission (e.g., avoid message bursts), and message sequencing. In addition, we have to make an effort to try to separate the transport functions from protocol processing. For example, if a protocol extension requires a natural RSVP session time-out (such as RSVP-TE one-to-one fast-reroute [FAST-REROUTE]), we have to turn off the staged refresh timers.
然而，在该机制的实现过程中，必须在每会话计时器维护、消息重传（例如，避免消息突发）和消息排序上花费大量精力。此外，我们必须努力将传输功能与协议处理分离。例如，如果协议扩展需要自然的RSVP会话超时（例如RSVP-TE一对一快速重路由[fast-reroute]），我们必须关闭分段刷新计时器。
According to RSVP [RFC2205], each RSVP message can only contain information for one session. In a network that has a reasonably large number of RSVP sessions, this constraint imposes a heavy processing burden on the routers. Many router OSes are based on UNIX. [PS00] showed that the UNIX socket I/O processing is not very sensitive to packet size. In fact, processing small packets takes almost as much CPU overhead as processing large ones. However, processing too many individual messages can easily cause congestion at socket I/O interfaces.
根据RSVP[RFC2205]，每个RSVP消息只能包含一个会话的信息。在具有相当多RSVP会话的网络中，此约束对路由器施加了沉重的处理负担。许多路由器操作系统都基于UNIX。[PS00]表明UNIX套接字I/O处理对数据包大小不太敏感。事实上，处理小数据包所需的CPU开销几乎与处理大数据包所需的CPU开销相同。但是，处理过多的单个消息很容易导致套接字I/O接口的拥塞。
To overcome this problem, RFC2961 introduced the message bundling mechanism. The bundling mechanism packs multiple RSVP messages between two adjacent nodes into a single packet. In one deployed router platform, the bundling mechanism has improved the number of RSVP sessions that a router can handle from 2,000 to over 7,000.
为了克服这个问题，RFC2961引入了消息绑定机制。捆绑机制将两个相邻节点之间的多个RSVP消息打包为一个数据包。在一个已部署的路由器平台中，捆绑机制将路由器可处理的RSVP会话数量从2000个提高到7000多个。
RSVP does not support message fragmentation and reassembly at protocol level. If the size of a RSVP message is larger than the link MTU, the message will be fragmented. The routers simply cannot detect and process RSVP message fragments.
RSVP不支持协议级别的消息分段和重组。如果RSVP消息的大小大于链接MTU，则消息将被分段。路由器根本无法检测和处理RSVP消息片段。
There is no solution for the MTU problem. Fortunately, at places where RSVP-TE has been used, either the amount of per-session RSVP data is never too large, or the link MTU is adjustable; PPP and Frame Relay can always increase or decrease the MTU sizes. For example, on some routers, a Frame Relay interface can support a link MTU size up to 9600 bytes. Currently, the RSVP MTU problem is not a realistic concern in MPLS networks.
MTU问题没有解决方案。幸运的是，在使用RSVP-TE的地方，每个会话的RSVP数据量永远不会太大，或者链路MTU是可调的；PPP和帧中继始终可以增加或减少MTU大小。例如，在某些路由器上，帧中继接口可以支持最大为9600字节的链路MTU。目前，在MPLS网络中，RSVP MTU问题不是一个现实问题。
However, when and if RSVP is used for end-user applications, for which network security is an essential and critical concern, it is possible that the size of RSVP messages can be larger than the link MTU. Note that end-users will most likely have to deal with a small 1500-byte Ethernet MTU.
然而，当且如果RSVP用于最终用户应用程序（网络安全是一个基本和关键问题）时，RSVP消息的大小可能大于链路MTU。请注意，最终用户很可能需要处理一个1500字节的小型以太网MTU。
RSVP-TE works in an environment that is different from what the original RSVP has been designed for: in MPLS networks, the RSVP sessions that are used to support Label-Switched Paths (LSPs) do not change frequently.
RSVP-TE的工作环境与原始RSVP的设计环境不同：在MPLS网络中，用于支持标签交换路径（LSP）的RSVP会话不会频繁更改。
In fact, the network operators typically set up the MPLS LSPs so that they cannot switch too quickly. For example, the operators often regulate the Constraint-based Shortest Path First (CSPF) computation interval to prevent or delay a large volume of user traffic from shifting from one session to another during LSP path optimization. (CSPF is a routing algorithm that operates from the network edge to compute the "most" optimal routes for the LSPs.) As a result, RSVP-TE does not have to handle a large amount of "triggered" (new or modified) messages. Most of the messages are refresh messages, which can be handled by the mechanisms introduced in RFC2961. In particular, in the Summary Refresh extension [RFC2961], each RSVP refresh message can be represented as a 4-byte ID. The routers can simply exchange the IDs to refresh RSVP sessions. With the full implementation of RFC2961, MPLS routers do not have any RSVP scaling issue. On one deployed router platform, it can support over 50,000 RSVP sessions in a stable backbone network.
事实上，网络运营商通常会设置MPLS LSP，这样他们就不会切换得太快。例如，运营商通常调整基于约束的最短路径优先（CSPF）计算间隔，以防止或延迟LSP路径优化期间大量用户流量从一个会话转移到另一个会话。（CSPF是一种从网络边缘运行的路由算法，用于计算LSP的“最”最优路由。）因此，RSVP-TE不必处理大量“触发”（新的或修改的）消息。大多数消息都是刷新消息，可以通过RFC2961中引入的机制进行处理。特别是，在摘要刷新扩展[RFC2961]中，每个RSVP刷新消息可以表示为一个4字节的ID。路由器可以简单地交换ID以刷新RSVP会话。随着RFC2961的全面实施，MPLS路由器没有任何RSVP扩展问题。在一个部署的路由器平台上，它可以在一个稳定的主干网络中支持50000多个RSVP会话。
On the other hand, in many of the new applications for which a signaling protocol is required, the user session duration can be relatively short. The dynamics of adding/dropping user sessions could introduce a large number of "triggered" messages in the network. This can clearly introduce a substantial amount of processing overhead to the routers. This is one area where a new signaling protocol may be needed to reduce the processing complexity in the resource reservation process.
另一方面，在许多需要信令协议的新应用中，用户会话持续时间可以相对较短。添加/删除用户会话的动态可能会在网络中引入大量“触发”消息。这显然会给路由器带来大量的处理开销。这是可能需要新的信令协议来降低资源预留过程中的处理复杂性的一个领域。
A good signaling protocol should be transparent to the applications. On the other hand, the design of a signaling protocol must take the intended and potential applications into consideration.
一个好的信令协议应该对应用程序透明。另一方面，信令协议的设计必须考虑预期的和潜在的应用。
With the addition of RFC2961, RSVP-TE is sufficient to support its intended application, MPLS, within the backbone. There is no significant transport-layer problem that needs to be solved.
通过添加RFC2961，RSVP-TE足以在主干网内支持其预期应用MPLS。没有需要解决的重大传输层问题。
In the last several years, a number of new applications have emerged that are proposed to need IP signaling, beyond the traditional ones associated with quality of service and resource allocation. On-path firewall control/NAT traversal (synergistic with the midcom design of [RFC3303]) is one of these. There are far-out applications such as depositing active network code in network devices. Next-generation signaling protocols dealing with novel applications, with network security requirements, and with the MTU problems described above, will prevent the re-use of the existing RSVP transport mechanism.
在过去几年中，出现了许多新的应用程序，它们被提议需要IP信令，而不仅仅是与服务质量和资源分配相关的传统应用程序。路径防火墙控制/NAT穿越（与[RFC3303]的midcom设计协同）就是其中之一。还有一些很遥远的应用，比如在网络设备中存放活动的网络代码。处理新应用、网络安全要求和上述MTU问题的下一代信令协议将阻止现有RSVP传输机制的重复使用。
If a new transport protocol is needed, the protocol must be able to handle the following:
如果需要新的传输协议，该协议必须能够处理以下内容：
- reliable messaging;
- 可靠的消息传递；
- message packing;
- 信息包装；
- the MTU problem;
- MTU问题；
- small triggered message volume.
- 触发的消息量小。
By "processing overhead" we mean the amount of processing required to handle messages belonging to a reservation session. This is the processing required in addition to the processing needed for routing an (ordinary) IP packet. The processing overhead of RSVP originates from two major issues:
“处理开销”是指处理属于保留会话的消息所需的处理量。这是除了路由（普通）IP数据包所需的处理之外所需的处理。RSVP的处理开销源自两个主要问题：
1) Complexity of the protocol elements. First, RSVP itself is per-flow based; thus the number of states is proportional to RSVP session number. Path and Resv states have to be maintained in each RSVP router for each session (and Path state also has to record the reverse route for the correspondent Resv message). Second, being receiver-initiated, RSVP optimizes various merging operations for multicast reservations while the Resv message is processed. To handle multicast, other mechanisms such as reservation styles, scope object, and blockade state, are also required to be presented in the basic protocol. This not only adds sources of failures and errors, but also complicates the state machine [Fu02]. Third, the same RSVP signaling messages are used not only for maintaining the state, but also for dealing with recovery of signaling message loss and discovery of route change. Thus, although protocol elements that represent the actual data (e.g., QoS parameters) specification are separated from signaling elements, the processing overhead needed for all RSVP messages is
1) 协议元素的复杂性。首先，RSVP本身是基于每个流的；因此，状态数与RSVP会话数成正比。对于每个会话，必须在每个RSVP路由器中维护路径和Resv状态（路径状态还必须记录对应的Resv消息的反向路由）。第二，在接收端启动时，RSVP在处理Resv消息时优化了多播保留的各种合并操作。要处理多播，还需要在基本协议中提供其他机制，如保留样式、作用域对象和封锁状态。这不仅增加了故障和错误的来源，而且使状态机变得复杂[Fu02]。第三，相同的RSVP信令消息不仅用于维护状态，还用于处理信令消息丢失的恢复和路由变化的发现。因此，尽管表示实际数据（例如，QoS参数）规范的协议元素与信令元素分离，但是所有RSVP消息所需的处理开销是有限的
not marginal. Finally, the possible variations of the order and existence of objects increases the complexity of message parsing and internal message and state representation.
不是边缘的。最后，对象的顺序和存在的可能变化增加了消息解析以及内部消息和状态表示的复杂性。
2) Implementation-specific Overhead. There are two ways to send and receive RSVP messages: either as "raw" IP datagrams with protocol number 46, or as encapsulated UDP datagrams, which increase the efficiency of RSVP processing. Typical RSVP implementations are user-space daemons interacting with the kernel; thus, state management, message sending, and reception would affect the efficiency of the protocol processing. For example, in the recent version of the implementation described in [KSS01], the relative execution costs for the message sending/reception system calls "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%, individually, of the total execution cost. [KSS01] also found that state (memory) management can use up to 17-18% of the total execution cost, but it is possible to decrease that cost to 6-7%, if appropriate action is taken to replace the standard memory management with dedicated memory management for state information. RSVP/routing, RSVP/policy control, and RSVP/traffic control interfaces can also pose different overhead depending on implementation. For example, the RSVP/routing overhead has been measured to be approximately 11-12% of the total execution cost [KSS01].
2) 特定于实现的开销。发送和接收RSVP消息有两种方式：作为协议号为46的“原始”IP数据报，或作为封装的UDP数据报，这提高了RSVP处理的效率。典型的RSVP实现是与内核交互的用户空间守护进程；因此，状态管理、消息发送和接收将影响协议处理的效率。例如，在[KSS01]中描述的最新版本的实现中，消息发送/接收系统调用“sendto”、“select”和“recvmsg”的相对执行成本分别占总执行成本的14-16%、6-7%、9-10%。[KSS01]还发现，状态（内存）管理最多可使用总执行成本的17-18%，但如果采取适当措施，用状态信息专用内存管理取代标准内存管理，则可以将该成本降低到6-7%。RSVP/路由、RSVP/策略控制和RSVP/流量控制接口也会根据实现带来不同的开销。例如，经测量，RSVP/路由开销约为总执行成本的11-12%[KSS01]。
By "bandwidth consumption" we mean the amount of bandwidth used during the lifetime of a session: to set up a reservation session, to keep the session alive, and finally to close it.
“带宽消耗”是指会话生命周期内使用的带宽量：设置保留会话、保持会话活动，最后关闭会话。
RSVP messages are sent either to trigger a new reservation or to refresh an existing reservation. In standard RSVP, Path/Resv messages are used for triggering and refreshing/recovering reservations, identically, which results in an increased size of refresh messages. The hop-by-hop refreshment may reduce the bandwidth consumption for RSVP, but could result in more sources of error/failure events. [RFC2961] presents a way to bundle standard RSVP messages and reduces the refreshment redundancy by Srefresh message.
发送RSVP消息以触发新预订或刷新现有预订。在标准RSVP中，Path/Resv消息同样用于触发和刷新/恢复保留，这导致刷新消息的大小增加。逐跳刷新可能会减少RSVP的带宽消耗，但可能会导致更多的错误/故障事件源。[RFC2961]提供了一种捆绑标准RSVP消息的方法，并通过Srefresh消息减少刷新冗余。
Thus, the following formula represents the bandwidth consumption in bytes for an RSVP session lasting n seconds:
因此，以下公式表示持续n秒的RSVP会话的带宽消耗（字节）：
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
bP: IP payload size of Path message bR: IP payload size of Resv message bPt: IP payload size of Path Tear message Ri: refresh interval
bP:路径消息的IP有效负载大小bR:Resv消息的IP有效负载大小bPt:路径撕裂消息的IP有效负载大小Ri:刷新间隔
For example, for a simple Controlled Load reservation without security and identification requirements (where bP is 172 bytes, bR is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth consumption would be as follows:
例如，对于没有安全和标识要求的简单受控负载预留（其中bP为172字节，bR为92，bPt为44字节，Ri为30秒），带宽消耗如下所示：
F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
= 308 + (264n/30) bytes
= 308 + (264n/30) bytes
To allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and to convey this information in RSVP messages (PATH or RESV) in a secure manner, [RFC3182] specifies the encoding of identities as RSVP POLICY_DATA Object. However, to provide ironclad security protection, cryptographic authentication combined with authorization has to be provided. Such a functionality is typically offered by authentication and key exchange protocols. Solely including a user identifier is insufficient.
为了允许系统上的进程安全地识别通信进程的所有者和应用程序（例如，用户id），并以安全的方式在RSVP消息（路径或RESV）中传递此信息，[RFC3182]将身份编码指定为RSVP策略_数据对象。然而，为了提供铁的安全保护，必须提供密码认证和授权。这种功能通常由身份验证和密钥交换协议提供。仅包含用户标识符是不够的。
To provide hop-by-hop integrity and authentication of RSVP messages, an RSVP message may contain an INTEGRITY object ([RFC2747]) using a keyed message digest. Since intermediate routers need to modify and process the content of the signaling message, a hop-by-hop security architecture based on a chain-of-trust is used. However, with the different usage of RSVP as described throughout this document and with new requirements, a re-evaluation of the original assumptions might be necessary.
为了提供RSVP消息的逐跳完整性和身份验证，RSVP消息可以包含使用密钥消息摘要的完整性对象（[RFC2747]）。由于中间路由器需要修改和处理信令消息的内容，因此使用了基于信任链的逐跳安全体系结构。然而，由于本文件中所述的RSVP的不同用法以及新的要求，可能需要重新评估原始假设。
RFC2747 provides protection against forgery and message modification. However, this does not provide non-repudiation or protect against message deletion. In the current RSVP security scheme, the two-way peer authentication and key management procedures are still missing.
RFC2747提供了防止伪造和消息修改的保护。但是，这并不提供不可否认性或防止消息删除。在当前的RSVP安全方案中，仍然缺少双向对等身份验证和密钥管理过程。
The security issues have been well analyzed in [Tsch03].
[Tsch03]对安全问题进行了详细分析。
Two issues raise concern when a mobile node (MN) uses RSVP: the flow identifier and reservation refresh. When an MN changes locations, it may need to change one of its assigned IP addresses. An MN may have an IP address by which it is reachable by nodes outside the access network, and an IP address used to support local mobility management. Depending on the mobility management mechanism, a handover may force a change in any of these addresses. As a consequence, the filters associated with a reservation may not identify the flow anymore, and the resource reservation is ineffective until a refresh with a new set of filters is initialized.
当移动节点（MN）使用RSVP时，有两个问题引起关注：流标识符和保留刷新。当MN更改位置时，它可能需要更改其分配的IP地址之一。MN可以具有接入网络之外的节点可通过其访问的IP地址，以及用于支持本地移动性管理的IP地址。根据移动性管理机制，切换可能会强制更改这些地址中的任何一个。因此，与保留关联的筛选器可能不再识别流，并且资源保留在使用一组新筛选器初始化刷新之前无效。
The second issue relates to following the movement of a mobile node. RFC2205 defines that Path messages can perform a local repair of reservation paths. When the route between the communicating end hosts changes, a Path message will set the state of the reservation on the new route, and a subsequent Resv message will make the resource reservation. Therefore, by sending a Resv message a host cannot alone update the reservation, and thus it cannot perform a local repair before a Path message has passed. Also, in order to provide fast adaptation to routing changes without the overhead of short refresh periods, the local routing protocol module can notify the RSVP process of route changes for particular destinations. The RSVP process should use this information to trigger a quick refresh of state for these destinations, using the new route (Section 3.6, [RFC2205]). However, not all local mobility protocols affect routing directly in routers (not even Mobile IP), and thus mobility may not be noticed at RSVP routers. Therefore, it may take a relatively long time before a reservation is refreshed following a handover.
第二个问题涉及跟踪移动节点的移动。RFC2205定义路径消息可以执行保留路径的本地修复。当通信终端主机之间的路由发生更改时，Path消息将设置新路由上的保留状态，随后的Resv消息将进行资源保留。因此，通过发送Resv消息，主机无法单独更新保留，因此无法在传递Path消息之前执行本地修复。此外，为了在没有短刷新周期的开销的情况下提供对路由变化的快速自适应，本地路由协议模块可以将特定目的地的路由变化通知RSVP过程。RSVP流程应使用该信息触发使用新路线（第3.6节[RFC2205]）快速刷新这些目的地的状态。然而，并非所有的本地移动性协议都直接影响路由器中的路由（甚至不是移动IP），因此在RSVP路由器上可能不会注意到移动性。因此，在切换之后刷新预订可能需要相对较长的时间。
There have been several designs for extensions to RSVP to allow for more seamless mobility. One solution is presented in [MSK+04], in which one section discusses the coupling of RSVP and the mobility management mechanisms and proposes small extensions to RSVP to handle the handover event better, among other things. The extension allows the mobile host to request a Path for the downstream reservation when a handover has happened.
RSVP有几种扩展设计，以实现更无缝的移动性。[MSK+04]中介绍了一种解决方案，其中一节讨论了RSVP和移动性管理机制的耦合，并提出了RSVP的小扩展，以更好地处理切换事件。该扩展允许移动主机在发生切换时请求下游预留的路径。
Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension to standard RSVP. It is based on advance reservations, where neighboring access points keep resources reserved for mobile nodes moving to their coverage area. When a mobile node requests resources, the neighboring access points are checked, too, and a passive reservation is done around the mobile nodes' current location.
另一个例子是移动RSVP（MRSVP）[TBA01]，它是标准RSVP的扩展。它基于预先预留，即相邻接入点为移动节点保留移动到其覆盖区域的资源。当移动节点请求资源时，也会检查相邻的接入点，并围绕移动节点的当前位置进行被动预约。
The problem with the various "advance reservation" schemes is that they require topological information of the access network and, usually, advance knowledge of the handover event. Furthermore, the way the resources reserved in advance are used in the neighboring service areas is an open issue. A good overview of these different schemes can be found in [MA01].
各种“提前预约”方案的问题在于，它们需要接入网络的拓扑信息，并且通常需要提前了解切换事件。此外，预先保留的资源在邻近服务区的使用方式也是一个悬而未决的问题。[MA01]中提供了这些不同方案的详细概述。
The interactions of RSVP and Mobile IP have been well documented in [Thom02].
RSVP和移动IP的相互作用已在[Thom02]中得到充分的记录。
Tenet and ST-II are two original QoS signaling protocols for the Internet.
Tenet和ST-II是两种原始的互联网QoS信令协议。
In the original Tenet architecture [BFM+96], the receiver sends a reservation request toward the source. Each network node along the way makes the reservation. Once the request arrives at the source, the source sends another Relax message back toward to the receiver, and has the option to modify the previous reservation at each node.
在最初的Tenet架构[BFM+96]中，接收方向源发送保留请求。沿途的每个网络节点都进行预订。一旦请求到达源，源就会向接收方发送另一条Relax消息，并且可以选择修改每个节点上以前的保留。
ST-II [RFC1819] basically works in the following way: a sender originates a Connect message to a set of receivers. Each intermediate node determines the next hop subnets, and makes reservations on the links going to these next hops. Upon receiving a Connect indication, a receiver must send back either an Accept or a Refuse message to the sender. In the case of an Accept, the receiver may further reduce the resource request by updating the returned flow specifications.
ST-II[RFC1819]的基本工作方式如下：发送方向一组接收方发送连接消息。每个中间节点确定下一跳子网，并对到这些下一跳的链路进行保留。接收到连接指示后，接收方必须向发送方发回接受或拒绝消息。在接受的情况下，接收器可以通过更新返回的流规范来进一步减少资源请求。
ST-II consists of two protocols: ST for the data transport and the Stream Control Message Protocol (SCMP) for all control functions. ST is simple and contains only a single PDU format, which is designed for fast and efficient data forwarding in order to achieve low communication delays. SCMP packets are transferred within ST packets.
ST-II由两个协议组成：用于数据传输的ST和用于所有控制功能的流控制消息协议（SCMP）。ST很简单，只包含一种PDU格式，该格式设计用于快速高效的数据转发，以实现较低的通信延迟。SCMP数据包在ST数据包内传输。
ST-II has no built-in soft states; thus, it requires that the network be responsible for correctness. It is sender-initiated, and the overhead for ST-II to handle group membership dynamics is higher than that for RSVP [MESZ94]. ST-II does not provide security, but [RFC1819] describes some objects related to charging.
ST-II没有内置的软状态；因此，它要求网络对正确性负责。它是由发送方发起的，ST-II处理组成员动态的开销高于RSVP[MESZ94]。ST-II不提供安全性，但[RFC1819]描述了一些与充电相关的对象。
YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a resource reservation protocol that seeks to simplify the process of establishing reserved flows while preserving many unique features introduced in RSVP. Simplicity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability, and resource sharing among multiple senders are also supported in the proposal.
YESSIR（另一个发送方会话Internet保留）[PS98]是一种资源保留协议，旨在简化建立保留流的过程，同时保留RSVP中引入的许多独特功能。简单性是根据控制消息处理、数据包处理和用户级灵活性来衡量的。该提案还支持健壮性、广告网络服务可用性和多个发件人之间的资源共享等功能。
The proposed mechanism generates reservation requests by senders to reduce the processing overhead. It is built as an extension to the Real-Time Transport Control Protocol (RTCP), taking advantage of Real-Time Protocol (RTP). YESSIR also introduces a concept called partial reservation, in which, for certain types of applications, the reservation requests can be passed to the next hop, even though there are not enough resources on a local node. The local node can rely on optimized retries to complete the reservations.
该机制通过发送方生成预约请求来减少处理开销。它是实时传输控制协议（RTCP）的扩展，利用了实时协议（RTP）。YESSIR还引入了一个称为部分保留的概念，在该概念中，对于某些类型的应用程序，保留请求可以传递到下一跳，即使本地节点上没有足够的资源。本地节点可以依靠优化的重试来完成保留。
YESSIR [PS98] was designed for one-way, sender-initiated end-to-end resource reservation. It also uses soft state to maintain states. It supports resource query (similar to RSVP diagnosis message), advertising (similar to RSVP ADSPEC), shared reservation, partial reservations, and flow merging.
YESSIR[PS98]设计用于单向、发送方发起的端到端资源预留。它还使用软状态来维护状态。它支持资源查询（类似于RSVP诊断消息）、广告（类似于RSVP ADSPEC）、共享保留、部分保留和流合并。
To support multicast, YESSIR simplifies the reservation styles to individual and shared reservation styles. Individual reservations are made separately for each sender, whereas shared reservations allocate resources that can be used by all senders in an RTP session. Although RSVP supports shared reservation (SE and WF styles) from the receiver's direction, YESSIR handles the shared reservation style from the sender's direction; thus, new receivers can re-use the existing reservation of the previous sender.
为了支持多播，YESSIR将保留样式简化为单独和共享保留样式。单独为每个发送者进行预订，而共享预订分配资源，供RTP会话中的所有发送者使用。虽然RSVP从接收方的角度支持共享保留（SE和WF样式），但YESSIR从发送方的角度处理共享保留样式；因此，新的接收者可以重新使用先前发送者的现有保留。
It has been shown that the YESSIR one-pass reservation model has better performance and lower processing cost than a regular two-way signaling protocol, such as RSVP [PS98]. The bandwidth consumption of YESSIR is somewhat lower than that of, for example, RSVP, because it does not require additional IP and transport headers. Bandwidth consumption is limited to the extension header size.
已经证明，与常规的双向信令协议（如RSVP[PS98]）相比，YESSIR单通预留模型具有更好的性能和更低的处理成本。YESSIR的带宽消耗略低于例如RSVP的带宽消耗，因为它不需要额外的IP和传输头。带宽消耗仅限于扩展标头大小。
YESSIR does not have any particular support for mobility, and the security of YESSIR relies on RTP/RTCP security measures.
YESSIR没有任何特定的移动性支持，YESSIR的安全性依赖于RTP/RTCP安全措施。
YESSIR requires support in applications since it is an integral part of RTCP. Similarly, it requires network routers to inspect RTCP packets to identify reservation requests and refreshes. Routers unaware of YESSIR forward the RTCP packets transparently.
YESSIR是RTCP不可分割的一部分，因此需要应用程序中的支持。类似地，它要求网络路由器检查RTCP数据包，以识别保留请求和刷新。不知道YESSIR的路由器透明地转发RTCP数据包。
Boomerang [FNM+99] is a another resource reservation protocol for IP networks. The protocol has only one message type and a single signaling loop for reservation setup and teardown, and it has no requirements on the far end node. Instead, it concentrates the intelligence in the Initiating Node (IN).
Boomerang[FNM+99]是IP网络的另一种资源预留协议。该协议只有一种消息类型和一个用于预约设置和拆卸的信令环路，对远端节点没有任何要求。相反，它将智能集中在发起节点（中）。
In addition, the Boomerang protocol allows for sender- or receiver-oriented reservations and resource query. Flows are identified with the common 5-tuple, and the QoS can be specified by various means; e.g., service class and bit rate. In the initial implementation, Boomerang messages are transported in ICMP ECHO/REPLY messages.
此外，回力棒协议允许面向发送方或接收方的预订和资源查询。流用公共五元组标识，QoS可以通过各种方式指定；e、 服务类别和比特率。在初始实现中，回力棒消息在ICMP回显/回复消息中传输。
Boomerang can only be used for unicast sessions; no support for multicast exists. The requested QoS can be specified with various methods, and both ends of a communication session can make a reservation for their transmitted flow.
回力棒只能用于单播会话；不支持多播。可以使用各种方法指定所请求的QoS，并且通信会话的两端可以对其传输的流进行预留。
The authors of Boomerang show in [FNS02] that the processing of the protocol is considerably lower than that of the ISI RSVP daemon implementation. However, this is mainly due to the limited functionality provided by the protocol compared to that provided by RSVP.
Boomerang的作者在[FNS02]中指出，协议的处理大大低于ISI RSVP守护程序实现的处理。然而，这主要是由于与RSVP提供的功能相比，协议提供的功能有限。
Boomerang messages are quite short and consume a relatively low amount of link bandwidth. This is due to the limited functionality of the protocol; for example, no security-specific information or policy-based interaction is provided. Being sender oriented, the bandwidth consumption mostly affects the downstream direction, from the sender to the receiver.
回力棒消息非常短，消耗的链路带宽相对较低。这是由于协议的功能有限；例如，没有提供特定于安全的信息或基于策略的交互。由于面向发送方，带宽消耗主要影响从发送方到接收方的下游方向。
As Boomerang is sender oriented, there is no need to store backward information. This reduces the signaling required. The rest of the issues that were identified with RSVP apply with Boomerang. No security mechanism is specified for Boomerang.
由于回力棒是面向发送者的，所以不需要存储向后的信息。这减少了所需的信令。RSVP确定的其他问题适用于回飞棒。没有为回飞棒指定安全机制。
The Boomerang protocol has deployment issues similar to those of any host-network-host protocol. It requires an implementation at both communicating nodes and in routers. Boomerang-unaware routers should be able to forward Boomerang messages transparently. Still, firewalls often drop ICMP packets, making the protocol useless.
Boomerang协议具有与任何主机网络主机协议类似的部署问题。它需要在通信节点和路由器上实现。不知道回飞镖的路由器应该能够透明地转发回飞镖消息。尽管如此，防火墙经常丢弃ICMP数据包，使得协议毫无用处。
Boomerang seems to be a very lightweight protocol and efficient in its own scenarios. However, the apparent low processing overhead and bandwidth consumption results from the limited functionality. No support for multicast or any security features are present, which allows for a different functionality than RSVP, which the authors like to compare Boomerang to.
Boomerang似乎是一个非常轻量级的协议，在自己的场景中非常有效。然而，由于功能有限，处理开销和带宽消耗明显较低。不支持多播或任何安全特性，这允许使用与RSVP不同的功能，作者喜欢将回力棒与RSVP进行比较。
INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism for supporting QoS in mobile ad-hoc networks. It avoids the need for separate signaling by carrying the QoS signaling data along with the normal data in IP packets using IP packet header options. This approach, known as "in-band signaling", is proposed as more suitable in the rapidly changing environment of mobile networks since the signaled QoS information is not tied to a particular path. It also allows the flows to be rapidly established and, thus, is suitable for short-lived and dynamic flows.
INSIGNIA[LGZC00]是一种非常简单的信令机制，用于支持移动自组织网络中的QoS。通过使用IP分组报头选项在IP分组中携带QoS信令数据和正常数据，它避免了单独信令的需要。这种称为“带内信令”的方法被认为更适合于快速变化的移动网络环境，因为信令的QoS信息不绑定到特定路径。它还允许快速建立流，因此适用于短期和动态流。
INSIGNIA aims to minimize signaling by reducing the number of parameters that are provided to the network. It assumes that real-time flows may tolerate some loss, but are very delay sensitive so that the only QoS information needed is the required minimum and maximum bandwidth.
INSIGNIA旨在通过减少提供给网络的参数数量来最小化信令。它假设实时流可以容忍一些损失，但对延迟非常敏感，因此所需的唯一QoS信息是所需的最小和最大带宽。
The INSIGNIA protocol operates at the network layer and assumes that link status sensing and access schemes are provided by lower-layer entities. The usefulness of the scheme depends on the MAC layers, but this is undefined, so INSIGNIA can run over any MAC layer. The protocol requires that each router maintains per-flow state.
INSIGNIA协议在网络层运行，并假设链路状态感知和访问方案由较低层实体提供。该方案的有用性取决于MAC层，但这是未定义的，因此INSIGNIA可以在任何MAC层上运行。协议要求每个路由器维护每个流状态。
The INSIGNIA system implicitly supports mobility. A near-minimal amount of information is exchanged with the network. To achieve this, INSIGNIA makes many assumptions about the nature of traffic that a source will send. This may also simplify admission control and buffer allocation. The system basically assumes that "real-time" will be defined as a maximum delay, and the user can simply request real-time service for a particular quantity of traffic.
INSIGNIA系统隐式支持移动性。与网络交换的信息量几乎是最小的。为了实现这一点，INSIGNIA对源将发送的流量的性质进行了许多假设。这还可以简化准入控制和缓冲区分配。系统基本上假设“实时”将被定义为最大延迟，用户可以简单地请求特定流量的实时服务。
After handover, data that was transmitted to the old base station can be forwarded to the new base station, so no data loss should occur. However, there is no way to differentiate between re-routed and new traffic, so priority cannot be given to handover traffic, for example.
切换后，传输到旧基站的数据可以转发到新基站，因此不会发生数据丢失。但是，无法区分重新路由的通信量和新的通信量，因此不能优先考虑切换通信量。
INSIGNIA, however, (completely) lacks a security framework and does not investigate how to secure signaled QoS data in an ad-hoc network, where relatively weak trust or even no trust exists between the participating nodes. Therefore, authorization and charging especially might be a challenge. The security protection of in-band signaling is costly since the data delivery itself experiences increased latency if security processing is done hop-by-hop. Because the QoS signaling information is encoded into the flow label and end-to-end addressing is used, it is very difficult to provide security other than IPsec in tunnel mode.
然而，INSIGNIA（完全）缺乏安全框架，并且没有研究如何在ad-hoc网络中保护信号QoS数据，在ad-hoc网络中，参与节点之间存在相对较弱的信任，甚至没有信任。因此，授权和收费可能是一个挑战。带内信令的安全保护成本很高，因为如果逐跳进行安全处理，数据传输本身会经历更大的延迟。由于QoS信令信息被编码到流标签中，并且使用端到端寻址，因此很难在隧道模式下提供IPsec以外的安全性。
This section gives a short overview of protocols designed for inter-domain signaling.
本节简要概述了为域间信令设计的协议。
Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling protocol for inter-domain aggregated resource reservation for unicast traffic. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. BGRP maintains these aggregated reservations using soft state and relies on Differentiated Services for data forwarding.
边界网关预留协议（BGRP）[BGRP]是一种用于单播业务的域间聚合资源预留的信令协议。BGRP为每个存根域构建一个接收器树。每个接收器树聚合网络中所有数据源的带宽保留。BGRP使用软状态维护这些聚合保留，并依赖差异化服务进行数据转发。
In terms of message processing load, BGRP scales state storage and bandwidth. Because backbone routers only maintain the sink tree information, the total number of reservations at each router scales linearly with the number of Internet domains.
在消息处理负载方面，BGRP扩展了状态存储和带宽。因为主干路由器只维护汇树信息，所以每个路由器上的保留总数与Internet域的数量成线性比例。
SICAP (Shared-segment Inter-domain Control Aggregation protocol) [SGV03] is an inter-domain signaling solution that performs shared-segment aggregation [SGV02] on the Autonomous System (AS) level in order to reduce state required at Boundary Routers (BRs). SICAP performs aggregation based on path segments that different reservations share. Thus, reservations may be merged into aggregates that do not necessarily extend all the way to the reservation's destination. The motivation for creating "shorter" aggregates is that, on one hand, their ability to accommodate future requests more easily, and, on the other hand, the minimization of aggregates
SICAP（共享段域间控制聚合协议）[SGV03]是一种域间信令解决方案，它在自治系统（AS）级别执行共享段聚合[SGV02]，以减少边界路由器（BRs）所需的状态。SICAP根据不同保留共享的路径段执行聚合。因此，可以将保留合并到聚合中，这些聚合不一定一直延伸到保留的目的地。创建“较短”聚合的动机是，一方面，它们能够更轻松地适应未来的请求，另一方面，最小化聚合
created and consequently, the reduction of state required to manage established reservations. However, in contrast to the sink-tree approach (used by BGRP [BGRP]), the shared-segment approach introduces intermediate de-aggregation locations. These are ASes where aggregates may experience "re-aggregation". At these locations, routers that perform aggregation (AS egress routers) have to keep track of the mapping between reservations and aggregates. One possible way to do this is to keep each reservation identifier and the corresponding resources stored at each aggregator. However, this solution incurs a high state penalty. SICAP avoids this state penalty by keeping track of the mapping between aggregates and reservations at the level of destination domains rather than explicitly map individual reservations to aggregates. In other words, SICAP maintains, per aggregate, a list of the destination prefixes advertised by the destination AS an aggregate provides access to.
因此，减少了管理既定保留所需的国家数量。然而，与汇树方法（由BGRP[BGRP]使用）相反，共享段方法引入了中间解聚集位置。在这些情况下，聚合可能会经历“重新聚合”。在这些位置，执行聚合的路由器（如出口路由器）必须跟踪保留和聚合之间的映射。一种可能的方法是将每个保留标识符和相应的资源存储在每个聚合器中。然而，这种解决方案会招致州政府的高额罚款。SICAP通过在目标域级别跟踪聚合和保留之间的映射，而不是显式地将单个保留映射到聚合，从而避免了这种状态惩罚。换言之，SICAP为每个聚合维护一个目标前缀列表，该列表由目标播发，作为一个聚合提供对的访问。
Pan et al. show that BGRP scales well in terms of control state, message processing, and bandwidth efficiency, when compared to RSVP without aggregation. However, partially given that BGRP was the first approach to explore the issue of inter-domain control aggregation in detail, they did not provide a comparison with other aggregation protocols.
Pan等人表明，与无聚合的RSVP相比，BGRP在控制状态、消息处理和带宽效率方面具有良好的扩展性。然而，部分地考虑到BGRP是第一个详细探讨域间控制聚合问题的方法，它们没有提供与其他聚合协议的比较。
SICAP and BGRP messaging sequences are similar, and consequently, these protocols attain the same signaling load. This load is exactly the same as that attained by proposals that do not perform aggregation, given that SICAP and BGRP exchange messages per individual reservation. In terms of bandwidth, both protocols provision aggregates with the exact bandwidth required by their merged reservations. Therefore, the major difference between SICAP and BGRP is state maintained at BRs, which is significantly reduced by SICAP. We consider this to be of importance not so much for offering a better-performing alternative to BGRP, but for quantifying the performance improvements that might still be available in the research field of control path aggregation. Finally, to deal with the possible problem of the signaling load, SICAP uses an over-reservation mechanism [SGV03b], whose design took into consideration a possible support for BGRP.
SICAP和BGRP消息传递序列相似，因此，这些协议获得相同的信令负载。考虑到SICAP和BGRP在每个预订中交换消息，该负载与不执行聚合的提案所获得的负载完全相同。就带宽而言，这两个协议都提供了合并保留所需的确切带宽。因此，SICAP和BGRP之间的主要区别在于BRs的状态保持，而SICAP显著降低了BRs的状态保持。我们认为这是重要的，而不是提供更好的性能替代BGRP，但量化性能改进，可能仍然可以在控制领域的研究路径聚合。最后，为了处理信令负载的可能问题，SICAP使用了一种过度保留机制[SGV03b]，其设计考虑了对BGRP的可能支持。
Dynamic Aggregation of Reservations for Internet Services (DARIS) [Bless02] [Bless04] defines an inter-domain aggregation scheme for resource reservations. Basically, it aggregates reservations along Autonomous System (AS) paths (or parts thereof). A set of reservations whose data paths share a common sequence of ASes are integrated into a joint reservation aggregate along that shared sub-
Internet服务保留的动态聚合（DARIS）[Bless02][Bless04]定义了资源保留的域间聚合方案。基本上，它沿着自治系统（AS）路径（或部分路径）聚合保留。数据路径共享ASE公共序列的一组保留被集成到沿该共享子系统的联合保留聚合中-
path. All entities within the aggregate, except for aggregate starting and end point, can remove state information of the included individual reservations, thereby saving states. They just need to hold the necessary information about the encompassing aggregate. Moreover, these intermediate ASes are no longer involved in signaling that is related to the aggregated reservations. If more aggregate resources are reserved than were actually required, the capacity of the aggregate does not need to be adapted with every new or released reservation (thereby reducing the number of message exchanges).
路径聚合中的所有实体（聚合起点和终点除外）都可以删除包含的单个保留的状态信息，从而保存状态。他们只需要保存关于包含的聚合的必要信息。此外，这些中间酶不再参与与聚集保留相关的信号传递。如果保留的聚合资源比实际需要的多，则聚合的容量不需要根据每个新的或释放的保留进行调整（从而减少消息交换的数量）。
An aggregate between two ASes is created as soon as a threshold k is exceeded that describes the active number of unidirectional reservations between them. It is, however, possible to apply different aggregation triggers. Furthermore, DARIS allows aggregates to be nested hierarchically. Therefore, the existence of shorter aggregates does not prevent the creation of longer (and thus more efficient) aggregates, and vice versa. An evaluation of recent BGP routing information in [Bless02] showed that 92% of all end-to-end paths contain at least four ASes. Consequently, an aggregate from edge AS to edge AS can span four or more ASes, thus saving states and signaling message processing in at least two ASes.
一旦超过描述两个ASE之间单向保留活动数量的阈值k，就会创建两个ASE之间的聚合。但是，可以应用不同的聚合触发器。此外，DARIS允许按层次嵌套聚合。因此，较短骨料的存在并不会阻止较长骨料（从而更有效）的创建，反之亦然。对[Bless02]中最近BGP路由信息的评估表明，92%的端到端路径至少包含四个ASE。因此，从边缘AS到边缘AS的聚合可以跨越四个或更多个ASE，从而在至少两个ASE中节省状态和信令消息处理。
There is, however, a small chance that a reservation cannot be included in a new aggregate, because it was already aggregated elsewhere. This so-called "aggregation conflict" is caused by the prior removal of state information related to individual reservations within intermediate ASes of the encompassing aggregate. This may also bring difficulties if reservations or aggregates are re-routed between ASes. One must be careful when considering how to define sophisticated adaptation techniques for these special cases, because they seem to become very complex.
但是，保留不能包含在新的聚合中的可能性很小，因为它已在其他地方聚合。这种所谓的“聚合冲突”是由于先前在包含聚合的中间ASE中删除了与单个保留相关的状态信息而造成的。如果在ASE之间重新路由保留或聚合，这也可能带来困难。在考虑如何为这些特殊情况定义复杂的适应技术时，必须小心，因为它们似乎变得非常复杂。
The signaling protocol DMSP (Domain Manager Signaling Protocol) supports aggregation by special extensions that reduce the reservation setup time for more than one round-trip time in some cases (e.g., if an aggregate's capacity must be increased before a new reservation can be included). Details can be found in [Bless02].
信令协议DMSP（域管理器信令协议）支持通过特殊扩展进行聚合，在某些情况下（例如，如果必须增加聚合的容量才能包括新的预约），这些扩展可以减少预约设置时间，使预约设置时间缩短一次以上。有关详细信息，请参见[Bless02]。
The DARIS concept was evaluated by using a simulation with a topology that was derived from real BGP routing table information and comprised more than 5500 ASes. In comparison to a non-aggregated scenario, the number of saved states lay in the range of one to two orders of magnitude, and similar results were obtained with respect to the number of signaling messages. Though [Bless02] describes DARIS in the context of distributed Domain Management entities (similar to a bandwidth broker), it can be applied in a router-based
DARIS概念是通过使用一个拓扑模拟进行评估的，该拓扑源自真实的BGP路由表信息，包含5500多个ASE。与非聚合场景相比，保存状态的数量在一到两个数量级的范围内，并且在信令消息的数量方面获得了类似的结果。尽管[Bless02]在分布式域管理实体（类似于带宽代理）的上下文中描述了DARI，但它可以应用于基于路由器的应用程序中
resource management environment, too. This will achieve a higher degree of distribution, which is beneficial for large ASes, which are highly interconnected.
资源管理环境也是如此。这将实现更高程度的分布，这有利于高度互联的大型ASE。
A general issue with aggregation is that it is not the aggregating and de-aggregating ASes that profit from their initiated aggregates, but all intermediate ASes within an aggregate. Therefore, some incentive for aggregate creation has to be given. This may lead to novel cost models that have to be developed for aggregation concepts in the future.
聚合的一个普遍问题是，不是聚合和反聚合的ASE从其初始聚合中获益，而是聚合中的所有中间ASE。因此，必须为总量创造提供一些激励。这可能导致未来必须为聚合概念开发新的成本模型。
This document does not present new technology or protocols. Thus, there are no explicit security issues. Still, individual protocols include different levels of security issues and those are highlighted in the relevant sections and references.
本文件不介绍新技术或协议。因此，没有明确的安全问题。尽管如此，各个协议包含不同级别的安全问题，这些问题在相关章节和参考文献中有重点介绍。
Supporting flow-based soft state reservations has been proven useful. Still, there have been different ways to improve the performance, including refresh reduction and aggregation. However, some of the main concerns with these signaling protocols are the complexity of the protocol, which affects implementations and processing overhead, and the security of the signaling. Especially, a proper scheme to handle authentication and authorization of QoS resource requests and a framework for providing signaling message security seem to be missing from most protocols. RSVP has a mechanism to protect signaling messages based on manually distributed keys and concepts for authorization, but they seem to be insufficient for a dynamic and mobile environment. [Tsch03] provides more details on security properties provided by RSVP. Moreover, secure and efficient signaling to and from mobile nodes has been one of the critical challenges not fully met by existing protocols.
支持基于流的软状态保留已被证明是有用的。尽管如此，仍然有不同的方法来提高性能，包括减少刷新和聚合。然而，这些信令协议的一些主要问题是协议的复杂性，这会影响实现和处理开销，以及信令的安全性。特别是，大多数协议似乎缺少处理QoS资源请求的身份验证和授权的适当方案以及提供信令消息安全性的框架。RSVP有一种基于手动分发的密钥和授权概念来保护信令消息的机制，但它们似乎不足以满足动态和移动环境的需要。[Tsch03]提供了有关RSVP提供的安全属性的更多详细信息。此外，安全和高效的移动节点之间的信令一直是现有协议无法完全满足的关键挑战之一。
Moving QoS signaling protocols into a generic messenger can provide much adoption. It is expected that the development of future protocols should learn from the lessons of existing ones. Nevertheless, the tradeoffs between the expected functionality, protocol complexity/performance would still be taken into account. For example, RSVP uses the two-way signaling mechanism, whereas YESSIR employs only one-pass signaling. Both can be shown to out-perform the other in specific carefully chosen signaling scenarios.
将QoS信令协议移动到通用信使中可以提供更多的采用。预计未来议定书的制定应吸取现有议定书的经验教训。尽管如此，仍将考虑预期功能、协议复杂性/性能之间的权衡。例如，RSVP使用双向信令机制，而YESSIR只使用一次传递信令。在特定的精心选择的信令场景中，两者的性能都可以超过另一个。
This document is part of the work done in the NSIS Working Group. The document was initially written by Jukka Manner and Xiaoming Fu. Since the first version, Martin Karsten has provided text about the processing overhead of RSVP, and Hannes Tschofenig has provided text about various security issues in the protocols. Henning Schulzrinne and Ping Pan have provided more information on RSVP transportation after the second revision. Kireeti Kompella and Adrian Farrel provided a review and updates to the discussion on RSVP-TE and GMPLS.
本文件是NSIS工作组工作的一部分。该文件最初由朱卡·韦德和傅晓明撰写。自第一个版本以来，Martin Karsten提供了关于RSVP处理开销的文本，Hannes Tschofenig提供了关于协议中各种安全问题的文本。Henning Schulzrinne和Ping Pan在第二次修订后提供了更多关于RSVP运输的信息。Kireeti Kompella和Adrian Farrel对RSVP-TE和GMPLS的讨论进行了回顾和更新。
We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments.
我们要感谢Bob Braden和Vlora Rexepi提出的有用意见。
This section provides a comparison of RSVP to the requirements identified as part of the work in NSIS [RFC3726]. The numbering follows the division in the requirements document.
本节将RSVP与NSIS[RFC3726]中确定为工作一部分的要求进行比较。编号遵循要求文件中的划分。
5.1. Architecture and Design Goals
5.1. 架构和设计目标
5.1.1. NSIS SHOULD Provide Availability Information on Request
5.1.1. NSIS应根据要求提供可用性信息
RSVP itself does not support query-type of operations. However, the RSVP diagnosis messages extension [RFC2745] provides a means to query resource availability.
RSVP本身不支持查询类型的操作。但是，RSVP诊断消息扩展[RFC2745]提供了一种查询资源可用性的方法。
5.1.2. NSIS MUST Be Designed Modularly
5.1.2. NSI必须模块化设计
RSVP was designed to be modular by way of TLV objects, however it is regarded being lack of sufficient extensibility in various kind of signalling applications.
RSVP被设计为通过TLV对象进行模块化，但在各种信令应用中缺乏足够的可扩展性。
5.1.3. NSIS MUST Decouple Protocol and Information
5.1.3. NSIS必须将协议和信息解耦
RSVP is decoupled from the IntServ QoS specifications. Still, the concept of sessions in RSVP are somewhat coupled to the information it carries.
RSVP与IntServ QoS规范分离。不过，RSVP中会话的概念在某种程度上与它所承载的信息相耦合。
5.1.4. NSIS MUST Support Independence of Signaling and Network Control Paradigm
5.1.4. NSIS必须支持信令和网络控制模式的独立性
The IntServ information carried by RSVP does not tie the QoS provisioning mechanisms.
RSVP携带的IntServ信息不绑定QoS提供机制。
5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects
5.1.5. NSIS应能携带不透明物体
RSVP supports this.
RSVP对此表示支持。
5.2. Signaling Flows
5.2. 信号流
5.2.1. The Placement of NSIS Initiator, Forwarder, and Responder Anywhere in the Network MUST Be Allowed
5.2.1. 必须允许在网络中的任何位置放置NSIS启动器、转发器和响应器
Standard RSVP works only end-to-end, although the RSVP proxy [BEGD02] and the Localized RSVP [MSK+04] have relaxed this assumption. RSVP relies on receiver-initiation way to perform QoS reservations.
标准RSVP只能端到端工作，尽管RSVP代理[BEGD02]和本地化RSVP[MSK+04]已经放宽了这一假设。RSVP依赖于接收机发起方式来执行QoS预留。
5.2.2. NSIS MUST support Path-Coupled and MAY Support Path-Decoupled Signaling
5.2.2. NSI必须支持路径耦合，并且可以支持路径解耦信令
Standard RSVP is path-coupled, but the Subnet Bandwidth Manager (SBM) work makes RSVP somewhat path-decoupled.
标准RSVP是路径耦合的，但子网带宽管理器（SBM）的工作使RSVP在某种程度上实现了路径解耦。
5.2.3. Concealment of Topology and Technology Information SHOULD Be Possible
5.2.3. 应能够隐藏拓扑和技术信息
RSVP itself does not provide such capability.
RSVP本身不提供这种能力。
5.2.4. Transparent Signaling through Networks SHOULD Be Possible
5.2.4. 通过网络的透明信令应该是可能的
RSVP messages are intercepted and evaluated in each RSVP router, and thus they may not cross certain RSVP-routers unnoticed. Still, the message processing rules allow unknown RSVP messages to be forwarded unharmed.
RSVP消息在每个RSVP路由器中被截获和评估，因此它们可能不会在未被注意的情况下穿越某些RSVP路由器。尽管如此，消息处理规则允许转发未知的RSVP消息而不受伤害。
5.3. Messaging
5.3. 消息传递
5.3.1. Explicit Erasure of State MUST Be Possible
5.3.1. 状态的显式擦除必须是可能的
Supported by the PathTear and ResvTear messages.
由PathTear和ResvTear消息支持。
5.3.2. Automatic Release of State After Failure MUST Be Possible
5.3.2. 必须能够在故障后自动释放状态
On error reservation states are torn down with PathTear messages.
错误时保留状态会被PathTear消息删除。
5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream
5.3.3. NSIS应允许向上游发送通知
There are two notifications in RSVP, confirm of a reservation set-up and tear down of reservation states as a result of errors.
RSVP中有两个通知，一个是确认预订设置，另一个是由于错误而取消预订状态。
5.3.4. Establishment and Refusal To Set Up State MUST Be Notified
5.3.4. 必须通知成立和拒绝成立国家
PathErr and ResvErr messages provide refusal to set up state in RSVP.
PathErr和ResvErr消息提供拒绝在RSVP中设置状态。
5.3.5. NSIS MUST Allow for Local Information Exchange
5.3.5. NSIS必须允许本地信息交换
RSVP NULL service type [RFC2997] provides such a feature.
RSVP NULL服务类型[RFC2997]提供了这样的功能。
5.4. Control Information
5.4. 控制信息
5.4.1. Mutability Information on Parameters SHOULD Be Possible
5.4.1. 参数的可变性信息应该是可能的
Rspec and Adspec are mutable; Tspec is (generally) end-to-end not mutable.
Rspec和Adspec是可变的；Tspec（通常）是端到端不可变的。
5.4.2. It SHOULD Be Possible To Add and Remove Local Domain Information
5.4.2. 应该可以添加和删除本地域信息
RSVP aggregation [RFC3175] and NULL service type [RFC2997] can provide such a feature.
RSVP聚合[RFC3175]和空服务类型[RFC2997]可以提供这样的功能。
5.4.3. State MUST Be Addressed Independent of Flow Identification
5.4.3. 状态必须独立于流标识进行处理
RSVP states are tied to the flows, thus this requirement is not met.
RSVP状态与流量相关，因此不满足此要求。
5.4.4. Modification of Already Established State SHOULD Be Seamless
5.4.4. 对已建立状态的修改应该是无缝的
Modifications of a reservation is possible with RSVP.
使用RSVP可以修改预订。
5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be Provided
5.4.5. 可以提供多个微流的信令分组
Aggregated RSVP and RFC2961 allow this.
聚合RSVP和RFC2961允许这样做。
5.5. Performance
5.5. 表演
5.5.1. Scalability
5.5.1. 可伸缩性
RSVP scales linearly to the number of reservation states.
RSVP与保留状态的数量成线性关系。
5.5.2. NSIS SHOULD Allow for Low Latency in Setup
5.5.2. NSIS应允许设置中的低延迟
Setting up an RSVP reservation takes one round-trip time and the processing times are each RSVP router.
设置RSVP预订需要一个往返时间，处理时间为每个RSVP路由器。
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling Protocol
5.5.3. NSI必须允许信令协议的低带宽消耗
The initial reservations messages can not be compressed, but the refresh interval can be adjusted to consume less bandwidth, at the expense of possible inefficient resource usage.
无法压缩初始保留消息，但可以调整刷新间隔以消耗较少的带宽，但可能会导致资源使用效率低下。
5.5.4. NSIS SHOULD Allow To Constrain Load on Devices
5.5.4. NSIS应允许约束设备上的负载
See discussions on RSVP performance (section 4).
见RSVP性能讨论（第4节）。
5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization
5.5.5. NSI应以尽可能高的网络利用率为目标
This depends on the IntServ service types, Controlled Load can provide better overall utilization than Guaranteed Service.
这取决于IntServ服务类型，受控负载可以提供比保证服务更好的总体利用率。
5.6. Flexibility
5.6. 灵活性
5.6.1. Flow Aggregation
5.6.1. 流聚合
Aggregated RSVP and RFC2961 allow this.
聚合RSVP和RFC2961允许这样做。
5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder
5.6.2. NSIS发起方/响应方位置的灵活性
RSVP allows receiver as initiator of reservations.
RSVP允许接收者作为预订的发起人。
5.6.3. Flexibility in the Initiation of State Change
5.6.3. 启动状态更改时的灵活性
RSVP receivers can initiate the state change during its refreshment.
RSVP接收器可以在刷新期间启动状态更改。
5.6.4. SHOULD Support Network-Initiated State Change
5.6.4. 应支持网络启动的状态更改
As RSVP supports hop-by-hop refreshment, this is made possible.
由于RSVP支持逐跳刷新，这是可能的。
5.6.5. Uni / Bi-Directional State Setup
5.6.5. 单向/双向状态设置
RSVP is only uni-directional.
RSVP只是单向的。
5.7. Security
5.7. 安全
5.7.1. Authentication of Signaling Requests
5.7.1. 信令请求的认证
Authentication is available in RSVP.
RSVP中提供身份验证。
5.7.2. Request Authorization
5.7.2. 请求授权
Authorization with a PDP is possible in RSVP.
可以在RSVP中使用PDP进行授权。
5.7.3. Integrity Protection
5.7.3. 完整性保护
The INTEGRITY Object is available in RSVP.
完整性对象在RSVP中可用。
5.7.4. Replay Protection
5.7.4. 重播保护
The INTEGRITY Object to replay protect the content of the signaling messages between two RSVP nodes.
重播的完整性对象保护两个RSVP节点之间的信令消息内容。
5.7.5. Hop-By-Hop Security
5.7.5. 逐跳安全
The RSVP security model works only hop-by-hop.
RSVP安全模型只能逐跳工作。
5.7.6. Identity Confidentiality and Network Topology Hiding
5.7.6. 身份保密与网络拓扑隐藏
The INTEGRITY Object can be used for this purpose.
INTEGRITY对象可用于此目的。
5.7.7. Denial-Of-Service Attacks
5.7.7. 拒绝服务攻击
Challenging with RSVP.
挑战RSVP。
5.7.8. Confidentiality of Signaling Messages
5.7.8. 信令消息的保密性
Not supported by RSVP.
RSVP不支持。
5.7.9. Ownership of State
5.7.9. 国家所有权
Challenging with RSVP.
挑战RSVP。
5.8. Mobility
5.8. 流动性
5.8.1. Allow Efficient Service Re-Establishment After Handover
5.8.1. 允许在移交后高效地重新建立服务
Works for upstream but may not be achieved for the downstream if mobility is not noticed at the cross-over router.
适用于上游，但如果在交叉路由器处未注意到移动性，则下游可能无法实现。
5.9. Interworking with Other Protocols and Techniques
5.9. 与其他协议和技术的互通
5.9.1. MUST Interwork with IP Tunneling
5.9.1. 必须与IP隧道互通
RFC 2746 discusses these issues.
RFC 2746讨论了这些问题。
5.9.2. MUST NOT Constrain either to IPv4 or IPv6
5.9.2. 不能约束到IPv4或IPv6
RSVP supports both IP versions.
RSVP支持两个IP版本。
5.9.3. MUST Be Independent from Charging Model
5.9.3. 必须独立于充电模式
RSVP does not discuss this.
RSVP没有讨论这一点。
5.9.4. SHOULD Provide Hooks for AAA Protocols
5.9.4. 应该为AAA协议提供挂钩
COPS and RSVP work together.
警察和RSVP一起工作。
5.9.5. SHOULD Work with Seamless Handoff Protocols
5.9.5. 应使用无缝切换协议
Not supported by RSVP. Still, [RFC2205] suggests that route changes should be indicated to the local RSVP daemon, which can then initiate state refresh.
RSVP不支持。尽管如此，[RFC2205]还是建议应该向本地RSVP守护进程指示路由更改，然后该守护进程可以启动状态刷新。
5.9.6. MUST Work with Traditional Routing
5.9.6. 必须使用传统路由
RSVP expects traditional routing.
RSVP需要传统的路由。
5.10. Operational
5.10. 操作的
5.10.1. Ability to Assign Transport Quality to Signaling Messages
5.10.1. 为信令消息分配传输质量的能力
This is a network design issue, but is possible with DiffServ.
这是一个网络设计问题，但在DiffServ中是可能的。
5.10.2. Graceful Fail Over
5.10.2. 优雅故障切换
RSVP supports this.
RSVP对此表示支持。
5.10.3. Graceful Handling of NSIS Entity Problems
5.10.3. NSIS实体问题的优雅处理
RSVP itself does not supports this.
RSVP本身不支持这一点。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]Brunner，M.，“信令协议的要求”，RFC 3726，2004年4月。
[3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service (QoS) Concept and Architecture, Release 5, December 2002.
[3GPP-TS23207]3GPP TS 23.207 V5.6.0，端到端服务质量（QoS）概念和体系结构，第5版，2002年12月。
[BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D. Zappala, "The Design of the RSVP Protocol", ISI Final Technical Report, July 1996.
[BEBH96]Braden，R.，Estrin，D.，Berson，S.，Herzog和D.Zappala，“RSVP协议的设计”，ISI最终技术报告，1996年7月。
[BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP Proxy", Work in Progress, March 2002.
[BEGD02]Y.Bernet、N.Elfasse、S.Gai和D.Dutt，“RSVP代理”，正在进行的工作，2002年3月。
[BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. Zhang, "The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences", IEEE/ACM Transactions on Networking, Volume 4, Issue 1, February 1996, pp. 1-10.
[BFM+96]A.Banerjea，D.Ferrari，B.Mah，M.Moran，D.Verma和H.Zhang，“特尼特实时协议套件：设计、实现和体验”，IEEE/ACM网络交易，第4卷，第1期，1996年2月，第1-10页。
[BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based Aggregation Protocol for Inter-domain Reservations", Journal of Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167.
[BGRP]P.Pan，E，Hahne和H.Schulzrinne，“BGRP：域间保留的基于树的聚合协议”，《通信与网络杂志》，第2卷，第2期，2000年6月，第157-167页。
[Bless02] R. Bless, "Dynamic Aggregation of Reservations for Internet Services", Proceedings of the Tenth International Conference on Telecommunication Systems - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38, October 3-6 2002, Monterey, California, available at http://www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdf.
[Bless02]R.Bless，“互联网服务预订的动态聚合”，《第十届国际电信系统会议记录——建模与分析》（ICTSM 10），第1卷，第26-38页，2002年10月3-6日，加利福尼亚州蒙特利，可在http://www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdf.
[Bless04] R. Bless, "Towards Scalable Management of QoS-based End-to- End Services" (PDF), Proceedings of NOMS 2004 (IEEE/IFIP 2004 Network Operations and Management Symposium), April 2004, Seoul, Korea.
[Bless04]R.Bless，“基于QoS的端到端服务的可扩展管理”（PDF），NOMS 2004年会议记录（IEEE/IFIP 2004网络运营和管理研讨会），2004年4月，韩国首尔。
[FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Work in Progress, January 2004.
[快速重路由]P.Pan，G.Swallow和A.Atlas，“LSP隧道RSVP-TE的快速重路由扩展”，正在进行的工作，2004年1月。
[FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for Resource Reservation in IP Networks", IEEE RTAS, 1999.
[FNM+99]G.Feher，K.Nemeth，M.Maliosz，I.Cselenyi，J.Bergkvist，D.Ahlard，T.Engborg，“回力棒——IP网络中资源预留的简单协议”，IEEE RTAS，1999年。
[FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance evaluation framework for IP resource reservation signalling". Performance Evaluation 48 (2002), pp. 131-156.
[FNS02]G.Feher，K.Nemeth和I.Cselenyi，“IP资源预留信令的性能评估框架”。业绩评价48（2002），第131-156页。
[FJ02] P. Fransson and A. Jonsson, "The need for an alternative to IPv4-options", in RVK (RadioVetenskap och Kommunikation), Stockholm, Sweden, pp. 162-166, June 2002.
[FJ02]P.Fransson和A.Jonsson，“IPv4选项替代方案的需要”，见RVK（RadioVetenskap och Kommunikation），瑞典斯德哥尔摩，第162-166页，2002年6月。
[Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP Regarding Multicast". Technical Report No. IFI-TB-2002-001, ISSN 1611-1044, Institute for Informatics, University of Goettingen, Oct 2002.
[Fu02]X.Fu，C.Kappler和H.Tschofenig，“关于多播的RSVP分析”。技术报告第IF-TB-2002 2-01，ISSN 1611-1044，信息科学研究所，哥廷根大学，OCT 2002。
[H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia Communication, July 2000.
[H.245]ITU-T建议H.245，多媒体通信控制协议，2000年7月。
[H.323] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, Nov. 2000.
[H.323]ITU-T建议H.323，基于分组的多媒体通信系统，2000年11月。
[JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS Management for Multimedia Applications in Wireless Access Networks". IASTED International Conference on Internet and Multimedia Systems and Applications (IMSA 2003), August, 2003, pp. 193-200.
[JR03]Jukka Way，Kimmo Raatikainen，“无线接入网络中多媒体应用的本地化QoS管理”。国际互联网和多媒体系统及应用国际会议（IMSA 2003），2003年8月，第193-200页。
[Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany, June 2001.
[Kars01]M.Karsten，“RSVP的实验性扩展——远程客户端和一次性信令”。IWQoS 2001，德国卡尔斯鲁厄，2001年6月。
[KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, "Implementation and Evaluation of the KOM RSVP Engine", IEEE Infocom 2001.
[KSS01]M.Karsten，Jens Schmitt，Ralf Steinmetz，“KOM RSVP引擎的实施和评估”，IEEE Infocom 2001。
[LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. Campbell,"INSIGNIA: An IP-Based Quality of Service Framework for Mobile Ad Hoc Networks". Journal of Parallel and Distributed Computing (Academic Press), Special issue on Wireless and Mobile Computing and Communications, Vol. 60, Number 4, April, 2000, pp. 374-406.
[LGZC00]S.Lee，A.Gahng Seop，X.Zhang，A.Campbell，“INSIGNIA：移动自组网基于IP的服务质量框架”。并行和分布式计算杂志（学术出版社），无线和移动计算与通信专刊，第60卷，第4期，2000年4月，第374-406页。
[MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real-Time Services in Wireless Mobile Networks". IEEE Communications Magazine, December 2001, pp. 52-59.
[MA01]B.Moon和H.Aghvami，“无线移动网络中实时服务的RSVP扩展”。IEEE通信杂志，2001年12月，第52-59页。
[MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An Architectural Comparison of ST-II and RSVP", Infocom 1994.
[MESZ94]D.Mitzel，D.Estrin，S.Shenker和L.Zhang，“ST-II和RSVP的建筑比较”，Infocom 1994。
[MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent deployment method of RSVP-aware applications on UNIX". Computer Networks, 40 (2002), pp. 45-56.
[MHS02]Y Miao、W.Hwang和C.Shieh，“UNIX上支持RSVP的应用程序的透明部署方法”。《计算机网络》，40（2002年），第45-56页。
[MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[MSK+04]J.Way，T.Suikko，M.Kojo，M.Liljeberg，K.Raatikainen，“本地化RSVP”，正在进行的工作，2004年9月。
[OVERLAY] G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter, "GMPLS UNI: RSVP Support for the Overlay Model", Work in Progress, February 2004.
[叠加]G.Swallow，J.Drake，H.Ishimatsu和Y.Rekhter，“GMPLS UNI:RSVP对叠加模型的支持”，正在进行的工作，2004年2月。
[PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for RSVP", Global Internet, Phoenix, Arizona, November 1997.
[PS97]P.Pan和H.Schulzrinne，“RSVP的分段刷新计时器”，全球互联网，亚利桑那州凤凰城，1997年11月。
[PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet". Proceedings of NOSSDAV, Cambridge, UK, July 1998.
[PS98]P.Pan和H.Schulzrinne，“YESSIR：一种简单的互联网预订机制”。1998年7月，英国剑桥NOSSDAV会议记录。
[PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel extension for IP option packet processing", Technical Memorandum 10009669-02TM, Bell Labs, Lucent Technologies, Murray Hill, NJ, June 2000.
[PS00]P.Pan和H.Schulzrinne，“PF_IPOPTION：IP选项包处理的内核扩展”，技术备忘录10009669-02TM，贝尔实验室，朗讯科技，新泽西州默里山，2000年6月。
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[RFC1819]Delgrossi，L.和L.Berger，“互联网流协议版本2（ST2）协议规范-版本ST2+”，RFC 18191995年8月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
[RFC2379]Berger，L.“ATM上的RSVP实施指南”，BCP 24，RFC 2379，1998年8月。
[RFC2380] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[RFC2380]Berger，L.“ATM实施要求的RSVP”，RFC 2380，1998年8月。
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC2745]Terzis，A.，Braden，B.，Vincent，S.，和L.Zhang，“RSVP诊断信息”，RFC 27452000年1月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[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月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[RFC2749]Herzog，S.，Boyle，J.，Cohen，R.，Durham，D.，Rajan，R.，和A.Sastry，“警察对RSVP的使用”，RFC 2749，2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks", RFC 2814, May 2000.
[RFC2814]Yavatkar，R.，Hoffman，D.，Bernet，Y.，Baker，F.，和M.Speer，“SBM（子网带宽管理器）：IEEE 802风格网络上基于RSVP的准入控制协议”，RFC 2814，2000年5月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996]Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[RFC2997]Bernet，Y.，Smith，A.，和B.Davie，“空服务类型的规范”，RFC 2997，2000年11月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 2998，2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[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月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303]Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC 33032002年8月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]Hamer，L-N.，Gage，B.，Kosinski，B.，和H.Shieh，“会话授权策略元素”，RFC 3520，2003年4月。
[SGV02] R. Sofia, R. Guerin, and P. Veiga, "An Investigation of Inter-Domain Control Aggregation Procedures", International Conference on Networking Protocols, ICNP 2002, Paris, France, November 2002.
[SGV02]R.Sofia、R.Guerin和P.Veiga，“域间控制聚合程序的研究”，网络协议国际会议，ICNP 2002，法国巴黎，2002年11月。
[SGV03] R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-segment Inter-domain Control Aggregation Protocol. High Performance Switching and Routing, HPSR 2003, Turin, Italy, June 2003.
[SGV03]R.Sofia、R.Guerin和P.Veiga。SICAP，一种共享段域间控制聚合协议。高性能交换和路由，HPSR 2003，意大利都灵，2003年6月。
[SGV03b] R. Sofia, R. Guerin, and P. Veiga. A Study of Over-reservation for Inter-Domain Control Aggregation Protocols. Technical report (short version under submission), University of Pennsylvania, May 2003, available at http://einstein.seas.upenn.edu/mnlab/ publications.html.
[SGV03b]R.索菲亚、R.盖林和P.维加。域间控制聚合协议的过度保留研究。技术报告（短版下提交），宾夕法尼亚大学，2003年5月，可在http://einstein.seas.upenn.edu/mnlab/ publications.html。
[TBA01] A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts", Wireless Networks, vol. 7, no. 1, pp. 5-19, 2001.
[TBA01]A.Talukdar，B.Badrinath和A.Acharya，“MRSVP：具有移动主机的综合服务网络的资源预留协议”，无线网络，第7卷，第1期，第5-19页，2001年。
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
[Thom02]M.Thomas，“移动IP和RSVP交互分析”，正在进行的工作，2002年10月。
[Tsch03] H. Tschofenig, "RSVP Security Properties", Work in Progress, February 2004.
[Tsch03]H.Tschofenig，“RSVP安全属性”，正在进行的工作，2004年2月。
[ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala, "RSVP: A New Resource Reservation Protocol", IEEE Network, Volume 7, Pages 8-18, September 1993.
[ZDSZ93]L.Zhang，S.Deering，D.Estrin和D.Zappala，“RSVP：一种新的资源预留协议”，IEEE网络，第7卷，第8-18页，1993年9月。
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[URL2] OPENSIG http://comet.columbia.edu/opensig/
[URL2] OPENSIG http://comet.columbia.edu/opensig/
[URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
siglite.html
[URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
siglite.html
Authors' Addresses
作者地址
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 68 (Gustav Hallstrominkatu 2b) FIN-00014 HELSINKI Finland
尤卡态度赫尔辛基大学计算机科学系P.O.Box 68（Gustav Hallstrominkatu 2B）FIF-000 014赫尔辛基芬兰
Phone: +358-9-191-51298
Fax: +358-9-191-51120
EMail: jmanner@cs.helsinki.fi
Phone: +358-9-191-51298
Fax: +358-9-191-51120
EMail: jmanner@cs.helsinki.fi
Xiaoming Fu Institute for Informatics Georg-August-University of Goettingen Lotzestrasse 16-18 37083 Goettingen Germany
傅晓明信息学院格奥尔格奥古斯特德国戈廷根大学洛泽斯特拉斯16-18 37083戈廷根
Phone: +49-551-39-14411
Fax: +49-551-39-14403
EMail: fu@cs.uni-goettingen.de
Phone: +49-551-39-14411
Fax: +49-551-39-14403
EMail: fu@cs.uni-goettingen.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。