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).




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.


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
1. Introduction
1. 介绍

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.


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.


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.


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.


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.


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.


2. RSVP and RSVP Extensions

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.


By original design, RSVP fits well into the framework of the Integrated Services (IntServ) [RFC2210] [BEBH96] with certain modularity and scalability.


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.


2.1. Basic Design
2.1. 基本设计

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.


2.1.1. Signaling Model
2.1.1. 信号模型

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


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.


2.1.2. Soft State
2.1.2. 软状态

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.


2.1.3. Two-Pass Signaling Message Exchanges
2.1.3. 双程信令消息交换

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请求可能会被合并,从而形成一个协议,该协议在有大量接收器时可以很好地扩展。

2.1.4. Receiver-Based Resource Reservation
2.1.4. 基于接收者的资源预留

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.


2.1.5. Separation of QoS Signaling from Routing
2.1.5. QoS信令与路由的分离

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.


A number of messages and objects have been defined for the protocol. A detailed description is given in [RFC2205].


2.2. RSVP Extensions
2.2. RSVP扩展

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.


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.


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.


2.2.1. Simple Tunneling
2.2.1. 简单隧道

[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.


2.2.2. IPsec Interface
2.2.2. IPsec接口

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)和一个新的会话对象。

2.2.3. Policy Interface
2.2.3. 策略接口

[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


content of the POLICY_DATA object itself is protected only between PEPs and therefore provides end-to-middle or middle-to-middle security.


[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.


2.2.4. Refresh Reduction
2.2.4. 刷新减少

[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消息。

2.2.5. RSVP over RSVP
2.2.5. RSVP对RSVP

[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:


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信令不会发生,因此不能用作触发器,因此需要一些额外的知识来设置聚合保留。

2.2.6. IEEE 802-Style LAN Interface
2.2.6. IEEE 802风格的局域网接口

[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.


2.2.7. ATM Interface
2.2.7. ATM接口

[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。

2.2.8. DiffServ Interface
2.2.8. 区分服务接口

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.


2.2.9. Null Service Type
2.2.9. 空服务类型

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发送方通常将包括识别用户、应用程序和子流的路径消息策略对象,这些对象将用于网络节点管理相应的业务流。

2.2.10. MPLS Traffic Engineering
2.2.10. MPLS流量工程

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.


RFC3209 defines a new Hello message (for rapid node failure detection).


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.


The following 5 new objects are also defined:


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]).


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:


- 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路径穿过未编号的链路。

2.2.11. GMPLS and RSVP-TE

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.


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的状态,并控制该状态)。

2.2.12. GMPLS Operation at UNI and E-NNI Reference Points
2.2.12. UNI和E-NNI参考点的GMPLS操作

The ITU-T defines network reference points that separate administrative or operational parts of the network. The reference points are designated as:


- 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].


2.2.13. MPLS and GMPLS Future Extensions
2.2.13. MPLS和GMPLS未来扩展

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.


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设置期间的回退。

2.2.14. ITU-T H.323 Interface
2.2.14. ITU-T H.323接口

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样式,即使对于点对多点调用也是如此。

2.2.15. 3GPP Interface
2.2.15. 3GPP接口

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.


2.3. Extensions for New Deployment Scenarios
2.3. 新部署场景的扩展

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 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 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


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.


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.


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.


2.4. Conclusion
2.4. 结论

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.


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 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 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.


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.


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.


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.


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.


The transport mechanisms, performance, security, and mobility issues are detailed in the following sections.


3. RSVP Transport Mechanism Issues
3. RSVP传输机制问题
3.1. Messaging Reliability
3.1. 消息传递可靠性

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.


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.


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.


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.


3.2. Message Packing
3.2. 消息打包

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.


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.


3.3. MTU Problem
3.3. MTU问题

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.


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.


3.4. RSVP-TE vs. Signaling Protocol for RT Applications
3.4. RSVP-TE与RT应用的信令协议

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.


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.


3.5. What Would Be a Better Alternative?
3.5. 有什么更好的选择?

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.


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.


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.

- 触发的消息量小。

4. RSVP Protocol Performance Issues
4. RSVP协议性能问题
4.1. Processing Overhead
4.1. 处理开销

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:


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]。

4.2. Bandwidth Consumption
4.2. 带宽消耗

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.


Thus, the following formula represents the bandwidth consumption in bytes for an RSVP session lasting n seconds:


      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


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:


      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
5. RSVP Security and Mobility
5. RSVP安全性和移动性
5.1. Security
5.1. 安全

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.


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.


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.


The security issues have been well analyzed in [Tsch03].


5.2. Mobility Support
5.2. 机动保障

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.


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.


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.


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.


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].


The interactions of RSVP and Mobile IP have been well documented in [Thom02].


6. Other QoS Signaling Proposals
6. 其他QoS信令方案
6.1. Tenet and ST-II
6.1. 特尼特和ST-II

Tenet and ST-II are two original QoS signaling protocols for the Internet.


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.


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 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 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.


6.2. 耶塞尔

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.


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.


6.2.1. Reservation Functionality
6.2.1. 预订功能

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.


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.


YESSIR does not have any particular support for mobility, and the security of YESSIR relies on RTP/RTCP security measures.


6.2.2. Conclusion
6.2.2. 结论

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.


6.3. Boomerang
6.3. 飞镖

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).


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回显/回复消息中传输。

6.3.1. Reservation Functionality
6.3.1. 预订功能

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.


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.


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.


6.3.2. Conclusions
6.3.2. 结论

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.


6.4. 标记

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 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.


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.


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.


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.


7. Inter-Domain Signaling
7. 域间信令

This section gives a short overview of protocols designed for inter-domain signaling.


7.1. BGRP
7.1. BGRP

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.


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.


7.2. SICAP
7.2. SICAP

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


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.


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.


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.


7.3. DARIS
7.3. 达利斯

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-


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.


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.


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].


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


resource management environment, too. This will achieve a higher degree of distribution, which is beneficial for large ASes, which are highly interconnected.


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.


8. Security Considerations
8. 安全考虑

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.


9. Summary
9. 总结

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.


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.


10. Contributors
10. 贡献者

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的讨论进行了回顾和更新。

11. Acknowledgements
11. 致谢

We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments.

我们要感谢Bob Braden和Vlora Rexepi提出的有用意见。

12. Appendix A: Comparison of RSVP to the NSIS Requirements
12. 附录A:RSVP与NSIS要求的比较

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.


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.


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.


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.


5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects

5.1.5. NSIS应能携带不透明物体

RSVP supports this.


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.


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.


5.2.3. Concealment of Topology and Technology Information SHOULD Be Possible

5.2.3. 应能够隐藏拓扑和技术信息

RSVP itself does not provide such capability.


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.


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.


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.


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.


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.


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.


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.


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.


5.4.4. Modification of Already Established State SHOULD Be Seamless

5.4.4. 对已建立状态的修改应该是无缝的

Modifications of a reservation is possible with RSVP.


5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be Provided

5.4.5. 可以提供多个微流的信令分组

Aggregated RSVP and RFC2961 allow this.


5.5. Performance

5.5. 表演

5.5.1. Scalability

5.5.1. 可伸缩性

RSVP scales linearly to the number of reservation states.


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.


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).


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.


5.6. Flexibility

5.6. 灵活性

5.6.1. Flow Aggregation

5.6.1. 流聚合

Aggregated RSVP and RFC2961 allow this.


5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder

5.6.2. NSIS发起方/响应方位置的灵活性

RSVP allows receiver as initiator of reservations.


5.6.3. Flexibility in the Initiation of State Change

5.6.3. 启动状态更改时的灵活性

RSVP receivers can initiate the state change during its refreshment.


5.6.4. SHOULD Support Network-Initiated State Change

5.6.4. 应支持网络启动的状态更改

As RSVP supports hop-by-hop refreshment, this is made possible.


5.6.5. Uni / Bi-Directional State Setup

5.6.5. 单向/双向状态设置

RSVP is only uni-directional.


5.7. Security

5.7. 安全

5.7.1. Authentication of Signaling Requests

5.7.1. 信令请求的认证

Authentication is available in RSVP.


5.7.2. Request Authorization

5.7.2. 请求授权

Authorization with a PDP is possible in RSVP.


5.7.3. Integrity Protection

5.7.3. 完整性保护

The INTEGRITY Object is available in 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.


5.7.5. Hop-By-Hop Security

5.7.5. 逐跳安全

The RSVP security model works only hop-by-hop.


5.7.6. Identity Confidentiality and Network Topology Hiding

5.7.6. 身份保密与网络拓扑隐藏

The INTEGRITY Object can be used for this purpose.


5.7.7. Denial-Of-Service Attacks

5.7.7. 拒绝服务攻击

Challenging with RSVP.


5.7.8. Confidentiality of Signaling Messages

5.7.8. 信令消息的保密性

Not supported by RSVP.


5.7.9. Ownership of State

5.7.9. 国家所有权

Challenging with 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.


5.9.3. MUST Be Independent from Charging Model

5.9.3. 必须独立于充电模式

RSVP does not discuss this.


5.9.4. SHOULD Provide Hooks for AAA Protocols

5.9.4. 应该为AAA协议提供挂钩

COPS and RSVP work together.


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.


5.9.6. MUST Work with Traditional Routing

5.9.6. 必须使用传统路由

RSVP expects traditional routing.


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.


5.10.2. Graceful Fail Over

5.10.2. 优雅故障切换

RSVP supports this.


5.10.3. Graceful Handling of NSIS Entity Problems

5.10.3. NSIS实体问题的优雅处理

RSVP itself does not supports this.


13. Normative References
13. 规范性引用文件

[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.

[RFC3726]Brunner,M.,“信令协议的要求”,RFC 3726,2004年4月。

14. Informative References
14. 资料性引用

[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.


[BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP Proxy", Work in Progress, March 2002.


[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.


[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.


[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

[Bless02]R.Bless,“互联网服务预订的动态聚合”,《第十届国际电信系统会议记录——建模与分析》(ICTSM 10),第1卷,第26-38页,2002年10月3-6日,加利福尼亚州蒙特利,可在

[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.


[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.


[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.323] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, Nov. 2000.


[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.


[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.


[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.


[PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet". Proceedings of NOSSDAV, Cambridge, UK, July 1998.


[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.


[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 publications.html.

[SGV03b]R.索菲亚、R.盖林和P.维加。域间控制聚合协议的过度保留研究。技术报告(短版下提交),宾夕法尼亚大学,2003年5月,可在 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.


[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.


[Tsch03] H. Tschofenig, "RSVP Security Properties", Work in Progress, February 2004.


[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.


   [URL2]         OPENSIG
   [URL2]         OPENSIG
   [URL3]         SIGLITE
   [URL3]         SIGLITE

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
   Phone: +358-9-191-51298
   Fax:   +358-9-191-51120

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
   Phone: +49-551-39-14411
   Fax:   +49-551-39-14403

Full Copyright Statement


Copyright (C) The Internet Society (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中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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


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




Funding for the RFC Editor function is currently provided by the Internet Society.