Network Working Group E. Crawley, Editor
Request for Comments: 2382 Argon Networks
Category: Informational L. Berger
Fore Systems
S. Berson
ISI
F. Baker
Cisco Systems
M. Borden
Bay Networks
J. Krawczyk
ArrowPoint Communications
August 1998
Network Working Group E. Crawley, Editor
Request for Comments: 2382 Argon Networks
Category: Informational L. Berger
Fore Systems
S. Berson
ISI
F. Baker
Cisco Systems
M. Borden
Bay Networks
J. Krawczyk
ArrowPoint Communications
August 1998
A Framework for Integrated Services and RSVP over ATM
ATM上的综合业务和RSVP框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.
本文件概述了通过ATM向RSVP提供IP综合服务的相关问题和框架。它提供了解决问题和相关问题的总体方法。这些问题将在ISSLL工作组ISATM小组的进一步文件中解决。
The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first-serve scheduling at each hop in the network. Best effort service has worked well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded portions of the network. In order to provide quality real-time traffic, new classes of service and a QoS signalling protocol are
互联网目前有一类服务，通常被称为“尽力而为”。这类服务的典型特征是在网络中的每个跃点进行先到先得的服务调度。“尽力而为”服务在电子邮件、万维网（WWW）访问、文件传输（如ftp）等方面表现良好。对于语音和视频等实时通信，当前的互联网仅在网络的未加载部分表现良好。为了提供高质量的实时流量，需要新的服务类别和QoS信令协议
being introduced in the Internet [1,6,7], while retaining the existing best effort service. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol and the service models
被引入互联网[1,6,7]，同时保留现有的尽力而为服务。QoS信令协议是RSVP[1]、资源预留协议和服务模型
One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be added and removed from the VC dynamically and so provides a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer including ATM, and this memo concentrates on ATM.
ATM技术的一个重要特征是能够请求具有特定服务质量（QoS）的点对点虚拟电路（VC）。ATM技术的另一个特点是能够请求具有指定QoS的点对多点VCs。点对多点VCs允许在VC中动态添加和删除叶节点，因此提供了一种支持IP多播的机制。RSVP和Internet集成服务（IIS）模型自然希望利用任何底层链路层（包括ATM）的QoS属性，本备忘录主要关注ATM。
Classical IP over ATM [10] has solved part of this problem, supporting IP unicast best effort traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within an LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is being solved with MARS [5], the Multicast Address Resolution Server.
经典的ATM上IP[10]解决了部分问题，支持ATM上的IP单播尽力而为流量。经典的IP over ATM基于逻辑IP子网（LIS），这是一个单独管理的IP子网。LIS中的主机使用ATM网络进行通信，而来自不同子网的主机仅通过IP路由器进行通信（即使可能通过ATM网络在两台主机之间打开直接VC）。经典的IP over ATM为ATM边缘设备提供了地址解析协议（ATMARP），用于将IP地址解析为本机ATM地址。对于任何一对IP/ATM边缘设备（即主机或路由器），根据需要创建一个VC，并为两个设备之间的所有流量共享。RSVP和IIS over ATM问题的第二部分，IP多播，正在通过多播地址解析服务器MARS[5]解决。
MARS compliments ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address.
MARS通过允许一个IP地址解析为一个本地ATM地址列表，而不仅仅是一个地址，对ATMARP进行了补充。
The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also address the support of IP best effort traffic over ATM through similar means.
ATM论坛的LAN仿真（LANE）[17,20]和ATM上的多协议（MPOA）[18]也通过类似的方式解决了ATM上IP尽力而为流量的支持问题。
A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs.
ATM环境中IP的一个关键遗留问题是RSVP信令和ATM信令的集成，以支持Internet集成服务（IIS）模型。支持IIS模型涉及两个主要方面：QoS转换和VC管理。QoS转换涉及将QoS从IIS模型映射到适当的ATM QoS，而VC管理集中于需要多少个VCs以及哪些流量通过哪些VCs路由。
This document provides a guide to the issues for IIS over ATM. It is intended to frame the problems that are to be addressed in further documents. In this document, the modes and models for RSVP operation over ATM will be discussed followed by a discussion of management of ATM VCs for RSVP data and control. Lastly, the topic of encapsulations will be discussed in relation to the models presented.
本文档提供了有关ATM上IIS问题的指南。其目的是界定将在进一步文件中解决的问题。在本文件中，将讨论ATM上RSVP操作的模式和模型，然后讨论用于RSVP数据和控制的ATM VCs的管理。最后，将结合所提供的模型讨论封装主题。
This document is part of a group of documents from the ISATM subgroup of the ISSLL working group related to the operation of IntServ and RSVP over ATM. [14] discusses the mapping of the IntServ models for Controlled Load and Guaranteed Service to ATM. [15 and 16] discuss detailed implementation requirements and guidelines for RSVP over ATM, respectively. While these documents may not address all the issues raised in this document, they should provide enough information for development of solutions for IntServ and RSVP over ATM.
本文件是ISSLL工作组ISATM子组的一组文件的一部分，涉及ATM上的IntServ和RSVP操作。[14] 讨论受控负载和保证服务的IntServ模型到ATM的映射。[15和16]分别讨论ATM上RSVP的详细实施要求和指南。虽然这些文档可能无法解决本文档中提出的所有问题，但它们应提供足够的信息，用于开发ATM上的IntServ和RSVP解决方案。
Several term used in this document are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
本文件中使用的几个术语在许多上下文中使用，通常具有不同的含义。本文件中使用的这些术语具有以下含义：
- Sender is used in this document to mean the ingress point to the ATM network or "cloud". - Receiver is used in this document to refer to the egress point from the ATM network or "cloud". - Reservation is used in this document to refer to an RSVP initiated request for resources. RSVP initiates requests for resources based on RESV message processing. RESV messages that simply refresh state do not trigger resource requests. Resource requests may be made based on RSVP sessions and RSVP reservation styles. RSVP styles dictate whether the reserved resources are used by one sender or shared by multiple senders. See [1] for details of each. Each new request is referred to in this document as an RSVP reservation, or simply reservation. - Flow is used to refer to the data traffic associated with a particular reservation. The specific meaning of flow is RSVP style dependent. For shared style reservations, there is one flow per session. For distinct style reservations, there is one flow per sender (per session).
- 在本文件中，发送方是指ATM网络或“云”的入口点本文件中的接收方指ATM网络或“云”的出口点本文档中的保留用于指RSVP发起的资源请求。RSVP根据RESV消息处理启动资源请求。仅刷新状态的RESV消息不会触发资源请求。资源请求可以基于RSVP会话和RSVP保留样式进行。RSVP样式决定保留资源是由一个发件人使用还是由多个发件人共享。请参见[1]了解每种方法的详细信息。每个新请求在本文件中称为RSVP保留，或简称保留。-流用于引用与特定保留相关联的数据通信量。流的具体含义取决于RSVP样式。对于共享样式保留，每个会话有一个流。对于不同样式的保留，每个发送者（每个会话）有一个流。
The issues related to RSVP and IntServ over ATM fall into several general classes:
与ATM上的RSVP和IntServ相关的问题可分为几类：
- How to make RSVP run over ATM now and in the future - When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP - How to map the IntServ models to ATM QoS models - How to know that an ATM network is providing the QoS necessary for a flow - How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to-many connection-oriented world of ATM
- 如何使RSVP在现在和将来通过ATM运行-何时为特定服务质量（QoS）设置虚拟电路（VC）与RSVP相关-如何将IntServ模型映射到ATM QoS模型-如何知道ATM网络正在提供流所需的QoS-如何在面向一对多连接的ATM世界中处理IP多播和RSVP的多对多无连接功能
[3] Discusses several different models for running IP over ATM networks. [17, 18, and 20] also provide models for IP in ATM environments. Any one of these models would work as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. It is important that the RSVP PATH messages follow the same IP path as the data such that appropriate PATH state may be installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points must be the same in both directions for the RSVP control and data messages. Note that the RSVP protocol does not require symmetric routing. The PATH state installed by RSVP allows the RESV messages to "retrace" the hops that the PATH message crossed. Within each of the models for IP over ATM, there are decisions about using different types of data distribution in ATM as well as different connection initiation. The following sections look at some of the different ways QoS connections can be set up for RSVP.
[3] 讨论在ATM网络上运行IP的几种不同模型。[17、18和20]还提供了ATM环境中的IP模型。只要RSVP控制包（IP协议46）和数据包可以通过网络遵循相同的IP路径，这些模型中的任何一个都可以工作。重要的是，RSVP PATH消息遵循与数据相同的IP路径，以便在路径沿线的路由器中安装适当的路径状态。对于ATM子网，这意味着RSVP控制和数据消息的入口和出口点在两个方向上必须相同。请注意，RSVP协议不需要对称路由。RSVP安装的路径状态允许RESV消息“回溯”路径消息跨越的跃点。在ATM上IP的每个模型中，都有关于在ATM中使用不同类型的数据分发以及不同的连接启动的决策。以下各节将介绍为RSVP设置QoS连接的一些不同方法。
In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9] and 4.0 specification, both permanent and switched virtual circuits (PVC and SVC) may be established with a specified service category (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and specific traffic descriptors in point-to-point and point-to-multipoint configurations. Additional QoS parameters are not available in UNI 3.x and those that are available are vendor-specific. Consequently, the level of QoS control available in standard UNI 3.x networks is somewhat limited. However, using these building blocks, it is possible to use RSVP and the IntServ models. ATM 4.0 with the Traffic Management (TM) 4.0 specification [21] allows much greater control of QoS. [14] provides the details of mapping the IntServ models to UNI 3.x and 4.0 service categories and traffic parameters.
在用户网络接口（UNI）3.0和3.1规范[8,9]和4.0规范中，永久和交换虚拟电路（PVC和SVC）都可以使用指定的服务类别（UNI 3.x的CBR、VBR和UBR以及4.0的VBR rt和ABR）建立以及点对点和点对多点配置中的特定流量描述符。UNI 3.x中没有其他QoS参数，可用的参数是特定于供应商的。因此，标准UNI 3.x网络中可用的QoS控制水平有些有限。但是，使用这些构建块，可以使用RSVP和IntServ模型。ATM 4.0和流量管理（TM）4.0规范[21]允许对QoS进行更大的控制。[14] 提供将IntServ模型映射到UNI 3.x和4.0服务类别和流量参数的详细信息。
PVCs emulate dedicated point-to-point lines in a network, so the operation of RSVP can be identical to the operation over any point-to-point network. The QoS of the PVC must be consistent and equivalent to the type of traffic and service model used. The devices on either end of the PVC have to provide traffic control services in order to multiplex multiple flows over the same PVC. With PVCs, there is no issue of when or how long it takes to set up VCs, since they are made in advance but the resources of the PVC are limited to what has been pre-allocated. PVCs that are not fully utilized can tie up ATM network resources that could be used for SVCs.
PVC模拟网络中的专用点到点线路，因此RSVP的操作可以与任何点到点网络上的操作相同。PVC的QoS必须与所使用的流量和服务模型的类型一致并等效。PVC两端的设备必须提供交通控制服务，以便在同一PVC上多路传输多个流。对于PVC，不存在设立VCs的时间或时间的问题，因为它们是预先制作的，但PVC的资源仅限于预先分配的资源。未充分利用的PVC会占用可用于SVC的ATM网络资源。
An additional issue for using PVCs is one of network engineering. Frequently, multiple PVCs are set up such that if all the PVCs were running at full capacity, the link would be over-subscribed. This frequently used "statistical multiplexing gain" makes providing IIS over PVCs very difficult and unreliable. Any application of IIS over PVCs has to be assured that the PVCs are able to receive all the requested QoS.
使用PVCs的另一个问题是网络工程。通常，设置多个PVC时，如果所有PVC都满负荷运行，则链路将被超额订阅。这种经常使用的“统计复用增益”使得通过PVC提供IIS变得非常困难和不可靠。任何通过PVC的IIS应用程序都必须确保PVC能够接收所有请求的QoS。
SVCs allow paths in the ATM network to be set up "on demand". This allows flexibility in the use of RSVP over ATM along with some complexity. Parallel VCs can be set up to allow best-effort and better service class paths through the network, as shown in Figure 1. The cost and time to set up SVCs can impact their use. For example, it may be better to initially route QoS traffic over existing VCs until a SVC with the desired QoS can be set up for the flow. Scaling issues can come into play if a single RSVP flow is used per VC, as will be discussed in Section 4.3.1.1. The number of VCs in any ATM device may also be limited so the number of RSVP flows that can be supported by a device can be strictly limited to the number of VCs available, if we assume one flow per VC. Section 4 discusses the topic of VC management for RSVP in greater detail.
SVC允许“按需”设置ATM网络中的路径。这使得在ATM上使用RSVP具有一定的灵活性和复杂性。可以设置并行VCs，以通过网络实现最佳努力和更好的服务类路径，如图1所示。设置SVC的成本和时间会影响其使用。例如，最好先在现有VCs上路由QoS流量，直到可以为该流设置具有所需QoS的SVC。如第4.3.1.1节所述，如果每个VC使用一个RSVP流，则可能会出现缩放问题。任何ATM设备中的VCs数量也可能受到限制，因此，如果我们假设每个VC有一个流，那么设备可以支持的RSVP流的数量可以严格限制为可用VCs的数量。第4节更详细地讨论了RSVP的VC管理主题。
Data Flow ==========>
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
Figure 1: Data Flow VC Initiation
图1：数据流VC初始化
While RSVP is receiver oriented, ATM is sender oriented. This might seem like a problem but the sender or ingress point receives RSVP RESV messages and can determine whether a new VC has to be set up to the destination or egress point.
RSVP面向接收方，ATM面向发送方。这似乎是个问题，但发送方或入口点接收RSVP RESV消息，并可以确定是否必须将新VC设置到目标或出口点。
In order to provide QoS for IP multicast, an important feature of RSVP, data flows must be distributed to multiple destinations from a given source. Point-to-multipoint VCs provide such a mechanism. It is important to map the actions of IP multicasting and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x and UNI 4.0 have a single service class for all destinations. This is contrary to the RSVP "heterogeneous receiver" concept. It is possible to set up a different VC to each receiver requesting a different QoS, as shown in Figure 2. This again can run into scaling and resource problems when managing multiple VCs on the same interface to different destinations.
为了为IP多播（RSVP的一个重要特性）提供QoS，数据流必须从给定的源分布到多个目的地。点对多点VCs提供了这种机制。映射IP多播和RSVP（例如IGMP加入/离开和RSVP RESV/RESV撕裂）的操作对于ATM的添加方和删除方功能非常重要。UNI 3.x和UNI 4.0中定义的点对多点VCs对所有目的地都有一个单一的服务类别。这与RSVP“异构接收器”的概念相反。可以为每个请求不同QoS的接收器设置不同的VC，如图2所示。当在同一接口上管理多个VCs到不同目的地时，这同样会遇到扩展和资源问题。
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Multicast
Group
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Multicast
Group
Figure 2: Types of Multicast Receivers
图2：多播接收器的类型
RSVP sends messages both up and down the multicast distribution tree. In the case of a large ATM cloud, this could result in a RSVP message implosion at an ATM ingress point with many receivers.
RSVP在多播分发树上下发送消息。在大型ATM云的情况下，这可能导致RSVP消息在具有多个接收器的ATM入口点内爆。
ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf Initiated Join (LIJ) capability. LIJ allows an ATM end point to join into an existing point-to-multipoint VC without necessarily contacting the source of the VC. This can reduce the burden on the ATM source point for setting up new branches and more closely matches the receiver-based model of RSVP and IP multicast. However, many of the same scaling issues exist and the new branches added to a point-to-multipoint VC must use the same QoS as existing branches.
ATM 4.0通过添加叶发起连接（LIJ）功能扩展了点对多点VCs。LIJ允许ATM端点加入现有的点对多点VC，而无需联系VC源。这可以减少ATM源点建立新分支的负担，并与基于接收器的RSVP和IP多播模型更加匹配。但是，存在许多相同的扩展问题，添加到点对多点VC的新分支必须使用与现有分支相同的QoS。
IP-over-ATM has the concept of a multicast server or reflector that can accept cells from multiple senders and send them via a point-to-multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server. Additionally, the multicast server will need to know how to interpret RSVP packets or receive instruction from another node so it will be able to provide VCs of the appropriate QoS for the RSVP flows.
ATM上的IP具有多播服务器或反射器的概念，它可以接受来自多个发送方的信元，并通过点对多点VC将信元发送到一组接收方。这将把前面提到的点对多点VCs的VC扩展问题转移到多播服务器。此外，多播服务器需要知道如何解释RSVP数据包或从另一个节点接收指令，以便能够为RSVP流提供具有适当QoS的VCs。
If the ATM "cloud" is made up a number of logical IP subnets (LISs), then it is possible to use "short cuts" from a node on one LIS directly to a node on another LIS, avoiding router hops between the LISs. NHRP [4], is one mechanism for determining the ATM address of the egress point on the ATM network given a destination IP address. It is a topic for further study to determine if significant benefit is achieved from short cut routes vs. the extra state required.
如果ATM“云”由多个逻辑IP子网（LIS）组成，则可以使用从一个LIS上的节点直接到另一个LIS上的节点的“捷径”，避免LIS之间的路由器跳变。NHRP[4]是一种机制，用于确定给定目的IP地址的ATM网络上出口点的ATM地址。这是一个有待进一步研究的课题，以确定是否从捷径路线与所需的额外状态中获得了显著的效益。
ATM is constantly evolving. If we assume that RSVP and IntServ applications are going to be wide-spread, it makes sense to consider changes to ATM that would improve the operation of RSVP and IntServ over ATM. Similarly, the RSVP protocol and IntServ models will continue to evolve and changes that affect them should also be considered. The following are a few ideas that have been discussed that would make the integration of the IntServ models and RSVP easier or more complete. They are presented here to encourage continued development and discussion of ideas that can help aid in the integration of RSVP, IntServ, and ATM.
ATM在不断发展。如果我们假设RSVP和ItServ应用程序将是广泛传播的，那么考虑ATM的改变是有意义的，这将改进ATM上RSVP和ItServ的操作。同样，RSVP协议和IntServ模型将继续发展，并应考虑影响它们的变化。以下是已经讨论过的一些想法，它们将使IntServ模型和RSVP的集成更容易或更完整。这里介绍它们是为了鼓励继续开发和讨论有助于RSVP、IntServ和ATM集成的想法。
The IntServ models and RSVP support the idea of "heterogeneous receivers"; e.g., not all receivers of a particular multicast flow are required to ask for the same QoS from the network, as shown in Figure 2.
IntServ模型和RSVP支持“异构接收器”的思想；e、 例如，并非特定多播流的所有接收器都需要从网络请求相同的QoS，如图2所示。
The most important scenario that can utilize this feature occurs when some receivers in an RSVP session ask for a specific QoS while others receive the flow with a best-effort service. In some cases where there are multiple senders on a shared-reservation flow (e.g., an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. However, other receivers may elect to reserve more resources, perhaps to allow for some amount of "over-speaking" or in order to record the conference (post processing during playback can separate the senders by their source addresses).
当RSVP会话中的一些接收器请求特定的QoS，而其他接收器则使用尽力而为的服务接收流时，可以利用此功能的最重要场景就会发生。在共享预订流（例如，音频会议）上有多个发送方的某些情况下，单个接收方只需保留足够的资源，即可一次接收一个发送方。然而，其他接收者可以选择保留更多资源，可能是为了允许一些“过度发言”或为了记录会议（回放期间的后处理可以根据发送者的源地址将发送者分开）。
In order to prevent denial-of-service attacks via reservations, the service models do not allow the service elements to simply drop non-conforming packets. For example, Controlled Load service model [7] assigns non-conformant packets to best-effort status (which may result in packet drops if there is congestion).
为了防止通过保留进行拒绝服务攻击，服务模型不允许服务元素简单地丢弃不一致的数据包。例如，受控负载服务模型[7]将不一致的数据包分配给尽力而为状态（如果出现拥塞，可能导致数据包丢失）。
Emulating these behaviors over an ATM network is problematic and needs to be studied. If a single maximum QoS is used over a point-to-multipoint VC, resources could be wasted if cells are sent over certain links where the reassembled packets will eventually be dropped. In addition, the "maximum QoS" may actually cause a degradation in service to the best-effort branches.
在ATM网络上模拟这些行为是有问题的，需要研究。如果在点对多点VC上使用单个最大QoS，那么如果在某些链路上发送小区，在这些链路上重新组装的数据包最终将被丢弃，则可能会浪费资源。此外，“最大QoS”实际上可能导致尽力而为分支的服务降级。
The term "variegated VC" has been coined to describe a point-to-multipoint VC that allows a different QoS on each branch. This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to be put into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one. The "best-effort for non-conforming packets" behavior must also be retained. Early Packet Discard (EPD) schemes must be used so that all the cells for a given packet can be discarded at the same time rather than discarding only a few cells from several packets making all the packets useless to the receivers.
术语“杂色VC”是用来描述一种点对多点VC，它在每个分支上允许不同的QoS。这种方法似乎符合集成服务和RSVP模型的精神，但在从“较大”分支到“较小”分支时，必须考虑小区丢弃策略。“不合格数据包的最大努力”行为也必须保留。必须使用早期分组丢弃（EPD）方案，以便可以同时丢弃给定分组的所有小区，而不是仅丢弃多个分组中的几个小区，从而使所有分组对接收器无用。
Q.2931 signalling is very complete and carries with it a significant burden for signalling in all possible public and private connections. It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks.
Q.2931信令是非常完整的，在所有可能的公共和私有连接中都会带来很大的信令负担。为了在专用网络中更快地建立连接，可能需要研究一种重量更轻的信令机制。
Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC. This would eliminate the need to setup and tear down VCs as the QoS changed. RSVP allows receivers to change their reservations and senders to change their traffic descriptors dynamically. This, along with the merging of reservations, can create a situation where the QoS needs of a VC can change. Allowing changes to the QoS of an existing VC would allow these features to work without creating a new VC. In the ITU-T ATM specifications [24,25], some cell rates can be renegotiated or changed. Specifically, the Peak Cell Rate (PCR) of an existing VC can be changed and, in some cases, QoS parameters may be renegotiated during the call setup phase. It is unclear if this is sufficient for the QoS renegotiation needs of the IntServ models.
另一个有助于ATM上RSVP的变化是为活动VC请求不同QoS的能力。这将消除在QoS改变时设置和拆除VCs的需要。RSVP允许接收者更改他们的预订，发送者动态更改他们的流量描述符。这与保留的合并一起，可能会造成VC的QoS需求发生变化的情况。允许更改现有VC的QoS将允许这些功能在不创建新VC的情况下工作。在ITU-T ATM规范[24,25]中，某些信元速率可以重新协商或更改。具体地说，可以改变现有VC的峰值小区速率（PCR），并且在某些情况下，可以在呼叫建立阶段重新协商QoS参数。目前尚不清楚这是否足以满足IntServ模型的QoS重新协商需求。
The model of one-to-many communications provided by point-to-multipoint VCs does not really match the many-to-many communications provided by IP multicasting. A scaleable mapping from IP multicast addresses to an ATM "group address" can address this problem.
点对多点VCs提供的一对多通信模型与IP多播提供的多对多通信模型并不匹配。从IP多播地址到ATM“组地址”的可伸缩映射可以解决这个问题。
The MultiProtocol Label Switching (MPLS) working group is discussing methods for optimizing the use of ATM and other switched networks for IP by encapsulating the data with a header that is used by the interior switches to achieve faster forwarding lookups. [22] discusses a framework for this work. It is unclear how this work will affect IntServ and RSVP over label switched networks but there may be some interactions.
多协议标签交换（MPLS）工作组正在讨论优化ATM和其他IP交换网络使用的方法，方法是使用内部交换机使用的报头封装数据，以实现更快的转发查找。[22]讨论了这项工作的框架。目前尚不清楚这项工作将如何影响标签交换网络上的IntServ和RSVP，但可能存在一些相互作用。
RSVP is explicitly not a routing protocol. However, since it conveys QoS information, it may prove to be a valuable input to a routing protocol that can make path determinations based on QoS and network load information. In other words, instead of asking for just the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow if routing has the ability to use this information in order to determine a route. Other forms of QoS routing have existed in the past such as using the IP TOS and Precedence bits to select a path through the network. Some have discussed using these same bits to select one of a set of parallel ATM VCs as a form of QoS routing. ATM routing has also considered the problem of QoS routing through the Private Network-to-Network Interface (PNNI) [26] routing protocol for routing ATM VCs on a path that can support their needs. The work in this area is just starting and there are numerous issues to consider. [23], as part of the work of the QoSR working group frame the issues for QoS Routing in the Internet.
RSVP显然不是路由协议。然而，由于它传递QoS信息，它可能被证明是路由协议的一个有价值的输入，该路由协议可以根据QoS和网络负载信息确定路径。换句话说，如果路由能够使用这些信息来确定路由，那么RSVP提供关于流的QoS需求的信息可能是值得的，而不是只要求给定目的地地址的IP下一跳。过去已经存在其他形式的QoS路由，例如使用IP TOS和优先位来选择通过网络的路径。一些人讨论了使用这些相同的比特从一组并行ATM VCs中选择一个作为QoS路由的形式。ATM路由还考虑了通过专用网络到网络接口（PNNI）[26]路由协议进行QoS路由的问题，用于在能够支持ATM VCs需求的路径上路由ATM VCs。这方面的工作刚刚起步，还有许多问题需要考虑。[23]，作为QoSR工作组工作的一部分，提出了互联网中QoS路由的问题。
RSVP was designed to support both unicast and IP multicast applications. This means that RSVP needs to work closely with multicast and unicast routing. Unicast routing over ATM has been addressed [10] and [11]. MARS [5] provides multicast address resolution for IP over ATM networks, an important part of the solution for multicast but still relies on multicast routing protocols to connect multicast senders and receivers on different subnets.
RSVP设计用于支持单播和IP多播应用。这意味着RSVP需要与多播和单播路由密切配合。ATM上的单播路由已被解决[10]和[11]。MARS[5]为IP over ATM网络提供多播地址解析，这是多播解决方案的重要组成部分，但仍然依赖多播路由协议来连接不同子网上的多播发送方和接收方。
Some of the scaling issues noted in previous sections can be addressed by aggregating several RSVP flows over a single VC if the destinations of the VC match for all the flows being aggregated. However, this causes considerable complexity in the management of VCs and in the scheduling of packets within each VC at the root point of
如果VC的目的地与正在聚合的所有流相匹配，则可以通过在单个VC上聚合多个RSVP流来解决前面章节中提到的一些扩展问题。然而，这在VC的管理以及在VC的根点处的每个VC内的分组调度方面造成了相当大的复杂性
the VC. Note that the rescheduling of flows within a VC is not possible in the switches in the core of the ATM network. Virtual Paths (VPs) can be used for aggregating multiple VCs. This topic is discussed in greater detail as it applies to multicast data distribution in section 4.2.3.4
风投。请注意，在ATM网络核心的交换机中，VC内的流重新调度是不可能的。虚拟路径（VP）可用于聚合多个VC。本主题将在第4.2.3.4节中详细讨论，因为它适用于多播数据分发
The mapping of QoS parameters from the IntServ models to the ATM service classes is an important issue in making RSVP and IntServ work over ATM. [14] addresses these issues very completely for the Controlled Load and Guaranteed Service models. An additional issue is that while some guidelines can be developed for mapping the parameters of a given service model to the traffic descriptors of an ATM traffic class, implementation variables, policy, and cost factors can make strict mapping problematic. So, a set of workable mappings that can be applied to different network requirements and scenarios is needed as long as the mappings can satisfy the needs of the service model(s).
将QoS参数从IntServ模型映射到ATM服务类是使RSVP和IntServ在ATM上工作的一个重要问题。[14] 对于受控负载和保证服务模型，完全解决了这些问题。另一个问题是，虽然可以制定一些准则，将给定服务模型的参数映射到ATM流量类别的流量描述符，但实现变量、策略和成本因素可能会使严格映射成为问题。因此，只要映射能够满足服务模型的需求，就需要一组可应用于不同网络需求和场景的可行映射。
It is obvious that the needs of hosts that are directly connected to ATM networks must be considered for RSVP and IntServ over ATM. Functionality for RSVP over ATM must not assume that an ATM host has all the functionality of a router, but such things as MARS and NHRP clients would be worthwhile features. A host must manage VCs just like any other ATM sender or receiver as described later in section 4.
显然，对于ATM上的RSVP和IntServ，必须考虑直接连接到ATM网络的主机的需求。ATM上RSVP的功能不能假设ATM主机具有路由器的所有功能，但MARS和NHRP客户端等功能是值得的。主机必须像第4节后面所述的任何其他ATM发送方或接收方一样管理VCs。
Since RSVP and IntServ create classes of preferential service, some form of administrative control and/or cost allocation is needed to control access. There are certain types of policies specific to ATM and IP over ATM that need to be studied to determine how they interoperate with the IP and IntServ policies being developed. Typical IP policies would be that only certain users are allowed to make reservations. This policy would translate well to IP over ATM due to the similarity to the mechanisms used for Call Admission Control (CAC).
由于RSVP和IntServ创建了优惠服务类别，因此需要某种形式的管理控制和/或成本分配来控制访问。需要研究特定于ATM和IP over ATM的某些类型的策略，以确定它们如何与正在开发的IP和IntServ策略互操作。典型的IP政策是只允许某些用户进行预订。由于与用于呼叫接纳控制（CAC）的机制相似，该策略可以很好地转换为ATM上的IP。
There may be a need for policies specific to IP over ATM. For example, since signalling costs in ATM are high relative to IP, an IP over ATM specific policy might restrict the ability to change the prevailing QoS in a VC. If VCs are relatively scarce, there also might be specific accounting costs in creating a new VC. The work so far has been preliminary, and much work remains to be done. The
可能需要针对ATM上IP的特定策略。例如，由于ATM中的信令成本相对IP而言较高，因此特定于IP over ATM的策略可能会限制VC中更改主要QoS的能力。如果风险投资相对较少，那么在创建新的风险投资时也可能会有特定的会计成本。迄今为止的工作是初步的，还有许多工作要做。这个
policy mechanisms outlined in [12] and [13] provide the basic mechanisms for implementing policies for RSVP and IntServ over any media, not just ATM.
[12]和[13]中概述的策略机制提供了在任何介质（而不仅仅是ATM）上实施RSVP和IntServ策略的基本机制。
Now that we have defined some of the issues for IntServ and RSVP over ATM, we can formulate a framework for solutions. The problem breaks down to two very distinct areas; the mapping of IntServ models to ATM service categories and QoS parameters and the operation of RSVP over ATM.
现在我们已经定义了ATM上的IntServ和RSVP的一些问题，我们可以为解决方案制定一个框架。这个问题分为两个截然不同的领域；IntServ模型到ATM服务类别和QoS参数的映射以及ATM上RSVP的操作。
Mapping IntServ models to ATM service categories and QoS parameters is a matter of determining which categories can support the goals of the service models and matching up the parameters and variables between the IntServ description and the ATM description(s). Since ATM has such a wide variety of service categories and parameters, more than one ATM service category should be able to support each of the two IntServ models. This will provide a good bit of flexibility in configuration and deployment. [14] examines this topic completely.
将IntServ模型映射到ATM服务类别和QoS参数是一个确定哪些类别可以支持服务模型的目标，并在IntServ描述和ATM描述之间匹配参数和变量的问题。由于ATM具有如此广泛的服务类别和参数，因此应该有多个ATM服务类别能够支持两种IntServ模型中的每一种。这将在配置和部署方面提供良好的灵活性。[14] 全面审视这个话题。
The operation of RSVP over ATM requires careful management of VCs in order to match the dynamics of the RSVP protocol. VCs need to be managed for both the RSVP QoS data and the RSVP signalling messages. The remainder of this document will discuss several approaches to managing VCs for RSVP and [15] and [16] discuss their application for implementations in term of interoperability requirement and implementation guidelines.
在ATM上运行RSVP需要仔细管理VCs，以匹配RSVP协议的动态。需要为RSVP QoS数据和RSVP信令消息管理VCs。本文件的其余部分将讨论为RSVP管理VCs的几种方法，[15]和[16]根据互操作性要求和实施指南讨论它们在实施中的应用。
This section provides more detail on the issues related to the management of SVCs for RSVP and IntServ.
本节提供了与RSVP和IntServ的SVC管理相关问题的更多详细信息。
As discussed in section 2.1.1.2, there is an apparent mismatch between RSVP and ATM. Specifically, RSVP control is receiver oriented and ATM control is sender oriented. This initially may seem like a major issue, but really is not. While RSVP reservation (RESV) requests are generated at the receiver, actual allocation of resources takes place at the subnet sender. For data flows, this means that subnet senders will establish all QoS VCs and the subnet receiver must be able to accept incoming QoS VCs, as illustrated in Figure 1. These restrictions are consistent with RSVP version 1 processing rules and allow senders to use different flow to VC mappings and even different QoS renegotiation techniques without
如第2.1.1.2节所述，RSVP和ATM之间存在明显的不匹配。具体来说，RSVP控制面向接收方，ATM控制面向发送方。这一点起初似乎是一个主要问题，但实际上并非如此。当RSVP保留（RESV）请求在接收方生成时，资源的实际分配在子网发送方进行。对于数据流，这意味着子网发送方将建立所有QoS VCs，子网接收方必须能够接受传入的QoS VCs，如图1所示。这些限制与RSVP版本1的处理规则一致，允许发送方使用不同的流到VC映射，甚至不同的QoS重新协商技术，而无需重新协商
interoperability problems.
互操作性问题。
The use of the reverse path provided by point-to-point VCs by receivers is for further study. There are two related issues. The first is that use of the reverse path requires the VC initiator to set appropriate reverse path QoS parameters. The second issue is that reverse paths are not available with point-to-multipoint VCs, so reverse paths could only be used to support unicast RSVP reservations.
接收机使用点对点VCs提供的反向路径有待进一步研究。有两个相关问题。首先，使用反向路径需要VC启动器设置适当的反向路径QoS参数。第二个问题是反向路径不适用于点对多点VCs，因此反向路径只能用于支持单播RSVP预留。
Any RSVP over ATM implementation must map RSVP and RSVP associated data flows to ATM Virtual Circuits (VCs). LAN Emulation [17], Classical IP [10] and, more recently, NHRP [4] discuss mapping IP traffic onto ATM SVCs, but they only cover a single QoS class, i.e., best effort traffic. When QoS is introduced, VC mapping must be revisited. For RSVP controlled QoS flows, one issue is VCs to use for QoS data flows.
ATM上的任何RSVP实现必须将RSVP和RSVP相关数据流映射到ATM虚拟电路（VCs）。LAN仿真[17]、经典IP[10]以及最近的NHRP[4]讨论了将IP流量映射到ATM SVC上，但它们只涵盖一个QoS类别，即尽力而为的流量。引入QoS时，必须重新检查VC映射。对于RSVP控制的QoS流，一个问题是用于QoS数据流的VCs。
In the Classic IP over ATM and current NHRP models, a single point-to-point VC is used for all traffic between two ATM attached hosts (routers and end-stations). It is likely that such a single VC will not be adequate or optimal when supporting data flows with multiple .bp QoS types. RSVP's basic purpose is to install support for flows with multiple QoS types, so it is essential for any RSVP over ATM solution to address VC usage for QoS data flows, as shown in Figure 1.
在经典的IP over ATM和当前的NHRP模型中，单点对点VC用于两个ATM连接主机（路由器和终端站）之间的所有流量。当支持具有多个.bp QoS类型的数据流时，这样一个VC可能是不够的或最优的。RSVP的基本目的是安装对具有多种QoS类型的流的支持，因此任何通过ATM的RSVP解决方案都必须解决QoS数据流的VC使用问题，如图1所示。
RSVP reservation styles must also be taken into account in any VC usage strategy.
在任何VC使用策略中，都必须考虑RSVP保留样式。
This section describes issues and methods for management of VCs associated with QoS data flows. When establishing and maintaining VCs, the subnet sender will need to deal with several complicating factors including multiple QoS reservations, requests for QoS changes, ATM short-cuts, and several multicast specific issues. The multicast specific issues result from the nature of ATM connections. The key multicast related issues are heterogeneity, data distribution, receiver transitions, and end-point identification.
本节描述与QoS数据流相关的VCs管理问题和方法。在建立和维护VCs时，子网发送方将需要处理几个复杂的因素，包括多个QoS保留、QoS更改请求、ATM快捷方式和几个特定于多播的问题。特定于多播的问题源于ATM连接的性质。与多播相关的关键问题是异构性、数据分布、接收器转换和端点识别。
There are various approaches available for mapping reservations on to VCs. A distinguishing attribute of all approaches is how reservations are combined on to individual VCs. When mapping reservations on to VCs, individual VCs can be used to support a single reservation, or reservation can be combined with others on to
有多种方法可用于将预订映射到VCs。所有方法的一个显著特征是如何将保留合并到单个风险投资中。将预订映射到VCs时，可以使用单个VCs来支持单个预订，也可以将预订与其他VCs组合到VCs
"aggregate" VCs. In the first case, each reservation will be supported by one or more VCs. Multicast reservation requests may translate into the setup of multiple VCs as is described in more detail in section 4.2.2. Unicast reservation requests will always translate into the setup of a single QoS VC. In both cases, each VC will only carry data associated with a single reservation. The greatest benefit if this approach is ease of implementation, but it comes at the cost of increased (VC) setup time and the consumption of greater number of VC and associated resources.
“聚合”风投。在第一种情况下，每个预订将由一个或多个VCs支持。如第4.2.2节所述，多播保留请求可转化为多个VCs的设置。单播预订请求将始终转换为单个QoS VC的设置。在这两种情况下，每个VC只携带与单个预订相关的数据。这种方法的最大好处是易于实现，但它以增加（VC）设置时间和消耗更多VC及相关资源为代价。
When multiple reservations are combined onto a single VC, it is referred to as the "aggregation" model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem (section 4.2.2) in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem (section 4.2.7) for ATM has also been reduced to a solved problem.
当多个预订组合到一个VC中时，它被称为“聚合”模型。通过这种模式，可以在ATM网络中的IP路由器和主机之间建立大型VCs。这些VCs可以像现在管理IP集成服务（IIS）点对点链路（例如T-1、DS-3）一样进行管理。来自多个RSVP会话的多个源的流量可能在同一个VC上多路复用。这种方法有许多优点。首先，通常没有信令延迟，因为当流量开始流动时VCs将存在，因此在设置VCs时不会浪费时间。第二，全覆盖ATM中的异构性问题（第4.2.2节）已被简化为一个已解决的问题。最后，ATM的动态QoS问题（第4.2.7节）也被简化为一个已解决的问题。
The aggregation model can be used with point-to-point and point-to-multipoint VCs. The problem with the aggregation model is that the choice of what QoS to use for the VCs may be difficult, without knowledge of the likely reservation types and sizes but is made easier since the VCs can be changed as needed.
聚合模型可用于点对点和点对多点VCs。聚合模型的问题是，在不知道可能的预订类型和大小的情况下，选择VCs使用的QoS可能很困难，但由于VCs可以根据需要进行更改，因此变得更容易。
Unicast data VC management is much simpler than multicast data VC management but there are still some similar issues. If one considers unicast to be a devolved case of multicast, then implementing the multicast solutions will cover unicast. However, some may want to consider unicast-only implementations. In these situations, the choice of using a single flow per VC or aggregation of flows onto a single VC remains but the problem of heterogeneity discussed in the following section is removed.
单播数据VC管理比多播数据VC管理简单得多，但仍存在一些类似的问题。如果认为单播是多播的一种转移情况，那么实现多播解决方案将涵盖单播。然而，有些人可能只考虑单播实现。在这些情况下，每个VC使用单个流或将流聚合到单个VC上的选择仍然存在，但下一节中讨论的异构性问题已经消除。
As mentioned in section 2.1.3.1 and shown in figure 2, multicast heterogeneity occurs when receivers request different qualities of service within a single session. This means that the amount of requested resources differs on a per next hop basis. A related type of heterogeneity occurs due to best-effort receivers. In any IP
如第2.1.3.1节所述和图2所示，当接收器在单个会话中请求不同的服务质量时，就会出现多播异构性。这意味着每个下一跳请求的资源量不同。由于尽力而为的接受者，出现了一种相关类型的异质性。在任何IP中
multicast group, it is possible that some receivers will request QoS (via RSVP) and some receivers will not. In shared media networks, like Ethernet, receivers that have not requested resources can typically be given identical service to those that have without complications. This is not the case with ATM. In ATM networks, any additional end-points of a VC must be explicitly added. There may be costs associated with adding the best-effort receiver, and there might not be adequate resources. An RSVP over ATM solution will need to support heterogeneous receivers even though ATM does not currently provide such support directly.
在多播组中，可能有些接收器将请求QoS（通过RSVP），而有些接收器将不请求QoS。在共享媒体网络（如以太网）中，未请求资源的接收器通常可以获得与已请求资源的接收器相同的服务，而不会出现复杂情况。ATM的情况并非如此。在ATM网络中，必须明确添加VC的任何附加端点。添加尽力而为接收者可能会产生相关成本，并且可能没有足够的资源。ATM上的RSVP解决方案将需要支持异构接收器，即使ATM目前不直接提供此类支持。
RSVP heterogeneity is supported over ATM in the way RSVP reservations are mapped into ATM VCs. There are four alternative approaches this mapping. There are multiple models for supporting RSVP heterogeneity over ATM. Section 4.2.3.1 examines the multiple VCs per RSVP reservation (or full heterogeneity) model where a single reservation can be forwarded onto several VCs each with a different QoS. Section 4.2.3.2 presents a limited heterogeneity model where exactly one QoS VC is used along with a best effort VC. Section 4.2.3.3 examines the VC per RSVP reservation (or homogeneous) model, where each RSVP reservation is mapped to a single ATM VC. Section 4.2.3.4 describes the aggregation model allowing aggregation of multiple RSVP reservations into a single VC.
通过将RSVP保留映射到ATM VCs的方式，在ATM上支持RSVP异构性。此映射有四种可选方法。有多种模型支持ATM上的RSVP异构性。第4.2.3.1节检查了每个RSVP保留（或完全异构）的多个VCs模型，其中单个保留可以转发到多个VCs，每个VCs具有不同的QoS。第4.2.3.2节介绍了一个有限的异构模型，其中仅使用了一个QoS VC和一个尽力而为的VC。第4.2.3.3节检查了每个RSVP保留（或同构）的VC模型，其中每个RSVP保留映射到单个ATM VC。第4.2.3.4节描述了允许将多个RSVP预订聚合到单个VC中的聚合模型。
RSVP supports heterogeneous QoS, meaning that different receivers of the same multicast group can request a different QoS. But importantly, some receivers might have no reservation at all and want to receive the traffic on a best effort service basis. The IP model allows receivers to join a multicast group at any time on a best effort basis, and it is important that ATM as part of the Internet continue to provide this service. We define the "full heterogeneity" model as providing a separate VC for each distinct QoS for a multicast session including best effort and one or more qualities of service.
RSVP支持异构QoS，这意味着同一组播组的不同接收者可以请求不同的QoS。但重要的是，一些接收者可能根本没有预订，希望在尽力而为的基础上接收流量。IP模式允许接收者在尽最大努力的基础上随时加入多播组，ATM作为互联网的一部分继续提供这项服务是很重要的。我们将“完全异构”模型定义为为为多播会话的每个不同QoS提供单独的VC，包括最大努力和一个或多个服务质量。
Note that while full heterogeneity gives users exactly what they request, it requires more resources of the network than other possible approaches. The exact amount of bandwidth used for duplicate traffic depends on the network topology and group membership.
请注意，尽管完全的异构性为用户提供了他们所需要的东西，但它比其他可能的方法需要更多的网络资源。用于复制流量的确切带宽量取决于网络拓扑和组成员资格。
We define the "limited heterogeneity" model as the case where the receivers of a multicast session are limited to use either best effort service or a single alternate quality of service. The alternate QoS can be chosen either by higher level protocols or by
我们将“有限异构性”模型定义为多播会话的接收者被限制使用尽力服务或单一替代服务质量的情况。备用QoS可以通过更高级别的协议或
dynamic renegotiation of QoS as described below.
QoS的动态重新协商，如下所述。
In order to support limited heterogeneity, each ATM edge device participating in a session would need at most two VCs. One VC would be a point-to-multipoint best effort service VC and would serve all best effort service IP destinations for this RSVP session.
为了支持有限的异构性，参与会话的每个ATM边缘设备最多需要两个VCs。一个VC将是点对多点尽力服务VC，并将为该RSVP会话的所有尽力服务IP目的地提供服务。
The other VC would be a point to multipoint VC with QoS and would serve all IP destinations for this RSVP session that have an RSVP reservation established.
另一个VC将是具有QoS的点对多点VC，并将为该RSVP会话的所有IP目的地提供服务，这些目的地已建立RSVP保留。
As with full heterogeneity, a disadvantage of the limited heterogeneity scheme is that each packet will need to be duplicated at the network layer and one copy sent into each of the 2 VCs. Again, the exact amount of excess traffic will depend on the network topology and group membership. If any of the existing QoS VC end-points cannot upgrade to the new QoS, then the new reservation fails though the resources exist for the new receiver.
与完全异构一样，有限异构方案的一个缺点是，每个数据包都需要在网络层进行复制，并向两个VCs中的每个VCs发送一个副本。同样，过量流量的确切数量将取决于网络拓扑和组成员资格。如果任何现有的QoS VC端点无法升级到新的QoS，则新的保留将失败，尽管新的接收器存在资源。
We define the "homogeneous" model as the case where all receivers of a multicast session use a single quality of service VC. Best-effort receivers also use the single RSVP triggered QoS VC. The single VC can be a point-to-point or point-to-multipoint as appropriate. The QoS VC is sized to provide the maximum resources requested by all RSVP next- hops.
我们将“同质”模型定义为多播会话的所有接收者使用单一服务质量的情况。尽力而为的接收机也使用单RSVP触发的QoS VC。单个VC可以是点对点或点对多点（视情况而定）。QoS VC的大小可以提供所有RSVP下一跳请求的最大资源。
This model matches the way the current RSVP specification addresses heterogeneous requests. The current processing rules and traffic control interface describe a model where the largest requested reservation for a specific outgoing interface is used in resource allocation, and traffic is transmitted at the higher rate to all next-hops. This approach would be the simplest method for RSVP over ATM implementations.
此模型与当前RSVP规范处理异构请求的方式相匹配。当前的处理规则和流量控制接口描述了一种模型，其中在资源分配中使用特定传出接口的最大请求预留，并且以更高的速率将流量传输到所有下一跳。这种方法将是通过ATM实现RSVP的最简单方法。
While this approach is simple to implement, providing better than best-effort service may actually be the opposite of what the user desires. There may be charges incurred or resources that are wrongfully allocated. There are two specific problems. The first problem is that a user making a small or no reservation would share a QoS VC resources without making (and perhaps paying for) an RSVP reservation. The second problem is that a receiver may not receive any data. This may occur when there is insufficient resources to add a receiver. The rejected user would not be added to the single VC and it would not even receive traffic on a best effort basis.
虽然这种方法易于实现，但提供比尽力而为更好的服务实际上可能与用户的期望相反。可能会产生费用或资源分配不当。有两个具体问题。第一个问题是，进行少量或无预订的用户将共享QoS VC资源，而无需进行RSVP预订（可能需要付费）。第二个问题是接收器可能无法接收任何数据。当没有足够的资源添加接收器时，可能会发生这种情况。被拒绝的用户将不会被添加到单个VC中，它甚至不会在尽最大努力的基础上接收流量。
Not sending data traffic to best-effort receivers because of another receiver's RSVP request is clearly unacceptable. The previously described limited heterogeneous model ensures that data is always sent to both QoS and best-effort receivers, but it does so by requiring replication of data at the sender in all cases. It is possible to extend the homogeneous model to both ensure that data is always sent to best-effort receivers and also to avoid replication in the normal case. This extension is to add special handling for the case where a best- effort receiver cannot be added to the QoS VC. In this case, a best effort VC can be established to any receivers that could not be added to the QoS VC. Only in this special error case would senders be required to replicate data. We define this approach as the "modified homogeneous" model.
由于另一个接收器的RSVP请求而不向尽力而为的接收器发送数据流量显然是不可接受的。前面描述的有限异构模型确保数据始终发送到QoS和尽力而为的接收器，但在所有情况下都需要在发送方复制数据。可以扩展同构模型，以确保数据始终发送给尽力而为的接收者，并且在正常情况下避免复制。这个扩展是为了在QoS VC中不能添加尽力而为的接收器的情况下添加特殊处理。在这种情况下，可以为无法添加到QoS VC的任何接收机建立尽力而为VC。只有在这种特殊的错误情况下，才会要求发送方复制数据。我们将这种方法定义为“修改的同质”模型。
The last scheme is the multiple RSVP reservations per VC (or aggregation) model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem for ATM has also been reduced to a solved problem. This approach can be used with point-to-point and point-to-multipoint VCs. The problem with the aggregation approach is that the choice of what QoS to use for which of the VCs is difficult, but is made easier if the VCs can be changed as needed.
最后一个方案是每个VC（或聚合）模型的多个RSVP保留。通过这种模式，可以在ATM网络中的IP路由器和主机之间建立大型VCs。这些VCs可以像现在管理IP集成服务（IIS）点对点链路（例如T-1、DS-3）一样进行管理。来自多个RSVP会话的多个源的流量可能在同一个VC上多路复用。这种方法有许多优点。首先，通常没有信令延迟，因为当流量开始流动时VCs将存在，因此在设置VCs时不会浪费时间。第二，全覆盖ATM中的异构性问题已被简化为一个已解决的问题。最后，ATM的动态QoS问题也被简化为一个已解决的问题。此方法可用于点对点和点对多点VCs。聚合方法的问题是，很难为哪一个VCs选择要使用的QoS，但是如果VCs可以根据需要进行更改，则会变得更容易。
Implementations must be able to identify ATM end-points participating in an IP multicast group. The ATM end-points will be IP multicast receivers and/or next-hops. Both QoS and best-effort end-points must be identified. RSVP next-hop information will provide QoS end-points, but not best-effort end-points. Another issue is identifying end-points of multicast traffic handled by non-RSVP capable next-hops. In this case a PATH message travels through a non-RSVP egress router on the way to the next hop RSVP node. When the next hop RSVP node sends a RESV message it may arrive at the source over a different route than what the data is using. The source will get the RESV message, but will not know which egress router needs the QoS. For unicast sessions, there is no problem since the ATM end-point will be the IP next-hop router. Unfortunately, multicast routing may
实现必须能够识别参与IP多播组的ATM端点。ATM端点将是IP多播接收器和/或下一跳。必须确定QoS和尽力而为的端点。RSVP下一跳信息将提供QoS端点，但不提供尽力而为的端点。另一个问题是识别由不支持RSVP的下一跳处理的多播流量的端点。在这种情况下，路径消息在到达下一跳RSVP节点的途中通过非RSVP出口路由器。当下一跳RSVP节点发送RESV消息时，它可能通过与数据使用的路由不同的路由到达源。源将获得RESV消息，但不知道哪个出口路由器需要QoS。对于单播会话，没有问题，因为ATM端点将是IP下一跳路由器。不幸的是，多播路由可能会失败
not be able to uniquely identify the IP next-hop router. So it is possible that a multicast end-point can not be identified.
无法唯一标识IP下一跳路由器。因此，可能无法识别多播端点。
In the most common case, MARS will be used to identify all end-points of a multicast group. In the router to router case, a multicast routing protocol may provide all next-hops for a particular multicast group. In either case, RSVP over ATM implementations must obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms. The full list can be compared against the RSVP identified end-points to determine the list of best-effort receivers. There is no straightforward solution to uniquely identifying end-points of multicast traffic handled by non-RSVP next hops. The preferred solution is to use multicast routing protocols that support unique end-point identification. In cases where such routing protocols are unavailable, all IP routers that will be used to support RSVP over ATM should support RSVP. To ensure proper behavior, implementations should, by default, only establish RSVP-initiated VCs to RSVP capable end-points.
在最常见的情况下，MARS将用于标识多播组的所有端点。在路由器到路由器的情况下，多播路由协议可以为特定多播组提供所有下一跳。在任何一种情况下，ATM上的RSVP实现都必须使用适当的机制获得完整的端点列表，包括QoS和非QoS。可将完整列表与确定的RSVP端点进行比较，以确定尽力而为的接收者列表。对于唯一标识由非RSVP下一跳处理的多播流量的端点，没有简单的解决方案。首选的解决方案是使用支持唯一端点标识的多播路由协议。在这种路由协议不可用的情况下，所有用于通过ATM支持RSVP的IP路由器都应支持RSVP。为确保正确的行为，默认情况下，实施应仅建立RSVP启动的VCs，以支持RSVP的端点。
Two models are planned for IP multicast data distribution over ATM. In one model, senders establish point-to-multipoint VCs to all ATM attached destinations, and data is then sent over these VCs. This model is often called "multicast mesh" or "VC mesh" mode distribution. In the second model, senders send data over point-to-point VCs to a central point and the central point relays the data onto point-to-multipoint VCs that have been established to all receivers of the IP multicast group. This model is often referred to as "multicast server" mode distribution. RSVP over ATM solutions must ensure that IP multicast data is distributed with appropriate QoS.
针对ATM上的IP组播数据分发，设计了两种模型。在一种模型中，发送方将点对多点VCs建立到所有ATM连接的目的地，然后通过这些VCs发送数据。这种模型通常被称为“多播网格”或“VC网格”模式分布。在第二种模型中，发送方通过点对点VCs向中心点发送数据，中心点将数据中继到已建立的点对多点VCs上，该VCs已发送到IP多播组的所有接收方。该模型通常被称为“多播服务器”模式分布。ATM上的RSVP解决方案必须确保IP多播数据以适当的QoS分发。
In the Classical IP context, multicast server support is provided via MARS [5]. MARS does not currently provide a way to communicate QoS requirements to a MARS multicast server. Therefore, RSVP over ATM implementations must, by default, support "mesh-mode" distribution for RSVP controlled multicast flows. When using multicast servers that do not support QoS requests, a sender must set the service, not global, break bit(s).
在经典IP上下文中，多播服务器支持是通过MARS提供的[5]。MARS目前不提供将QoS要求传达给MARS多播服务器的方法。因此，ATM上的RSVP实现在默认情况下必须支持RSVP控制的多播流的“网状模式”分布。当使用不支持QoS请求的多播服务器时，发送方必须设置服务（而不是全局）中断位。
When setting up a point-to-multipoint VCs for multicast RSVP sessions, there will be a time when some receivers have been added to a QoS VC and some have not. During such transition times it is possible to start sending data on the newly established VC. The issue is when to start send data on the new VC. If data is sent both on the new VC and the old VC, then data will be delivered with proper
在为多播RSVP会话设置点对多点VCs时，会有一段时间，一些接收器已添加到QoS VC，而一些尚未添加。在这种转换期间，可以在新建立的VC上开始发送数据。问题是何时开始在新VC上发送数据。如果数据同时在新VC和旧VC上发送，则数据将以适当的方式发送
QoS to some receivers and with the old QoS to all receivers. This means the QoS receivers can get duplicate data. If data is sent just on the new QoS VC, the receivers that have not yet been added will lose information. So, the issue comes down to whether to send to both the old and new VCs, or to send to just one of the VCs. In one case duplicate information will be received, in the other some information may not be received.
对某些接收器的QoS和对所有接收器的旧QoS。这意味着QoS接收器可以获得重复数据。如果数据仅在新的QoS VC上发送，则尚未添加的接收器将丢失信息。因此，问题归结为是同时发送给新旧风险投资公司，还是只发送给其中一家风险投资公司。在一种情况下，将收到重复的信息，而在另一种情况下，可能无法收到某些信息。
This issue needs to be considered for three cases:
在三种情况下需要考虑这个问题：
- When establishing the first QoS VC - When establishing a VC to support a QoS change - When adding a new end-point to an already established QoS VC
- 在建立第一个QoS VC时-在建立支持QoS更改的VC时-在向已建立的QoS VC添加新端点时
The first two cases are very similar. It both, it is possible to send data on the partially completed new VC, and the issue of duplicate versus lost information is the same. The last case is when an end-point must be added to an existing QoS VC. In this case the end-point must be both added to the QoS VC and dropped from a best-effort VC. The issue is which to do first. If the add is first requested, then the end-point may get duplicate information. If the drop is requested first, then the end-point may loose information.
前两个案例非常相似。这两者都有可能在部分完成的新VC上发送数据，重复与丢失信息的问题是相同的。最后一种情况是必须将端点添加到现有QoS VC。在这种情况下，端点必须既添加到QoS VC中，又从尽力而为的VC中删除。问题是先做什么。如果首次请求添加，则端点可能会获得重复信息。如果首先请求放置，则端点可能会丢失信息。
In order to ensure predictable behavior and delivery of data to all receivers, data can only be sent on a new VCs once all parties have been added. This will ensure that all data is only delivered once to all receivers. This approach does not quite apply for the last case. In the last case, the add operation should be completed first, then the drop operation. This means that receivers must be prepared to receive some duplicate packets at times of QoS setup.
为了确保可预测的行为和向所有接收者传送数据，只有在添加所有各方后，才能在新的VCs上发送数据。这将确保所有数据只向所有接收器发送一次。这种方法并不完全适用于最后一种情况。在最后一种情况下，应首先完成添加操作，然后完成删除操作。这意味着接收器必须准备好在QoS设置时接收一些重复的数据包。
RSVP provides dynamic quality of service (QoS) in that the resources that are requested may change at any time. There are several common reasons for a change of reservation QoS.
RSVP提供动态服务质量（QoS），因为请求的资源可能随时发生变化。更改预订QoS有几个常见的原因。
1. An existing receiver can request a new larger (or smaller) QoS. 2. A sender may change its traffic specification (TSpec), which can trigger a change in the reservation requests of the receivers. 3. A new sender can start sending to a multicast group with a larger traffic specification than existing senders, triggering larger reservations. 4. A new receiver can make a reservation that is larger than existing reservations.
1. 现有接收器可以请求新的更大（或更小）的QoS。2.发送方可以更改其流量规范（TSpec），这可以触发接收方的预约请求的更改。3.新的发送方可以开始向具有比现有发送方更大流量规范的多播组发送，从而触发更大的保留。4.新的接收者可以进行比现有预订更大的预订。
If the limited heterogeneity model is being used and the merge node for the larger reservation is an ATM edge device, a new larger reservation must be set up across the ATM network. Since ATM service, as currently defined in UNI 3.x and UNI 4.0, does not allow renegotiating the QoS of a VC, dynamically changing the reservation means creating a new VC with the new QoS, and tearing down an established VC. Tearing down a VC and setting up a new VC in ATM are complex operations that involve a non-trivial amount of processing time, and may have a substantial latency. There are several options for dealing with this mismatch in service. A specific approach will need to be a part of any RSVP over ATM solution.
如果使用有限的异构模型，并且较大保留的合并节点是ATM边缘设备，则必须在ATM网络上设置新的较大保留。由于UNI 3.x和UNI 4.0中当前定义的ATM服务不允许重新协商VC的QoS，因此动态更改保留意味着创建具有新QoS的新VC，并拆除已建立的VC。在ATM中拆除VC和设置新VC是一项复杂的操作，涉及大量的处理时间，并且可能有很大的延迟。有几个选项可以处理服务中的这种不匹配。特定的方法将需要成为任何RSVP over ATM解决方案的一部分。
The default method for supporting changes in RSVP reservations is to attempt to replace an existing VC with a new appropriately sized VC. During setup of the replacement VC, the old VC must be left in place unmodified. The old VC is left unmodified to minimize interruption of QoS data delivery. Once the replacement VC is established, data transmission is shifted to the new VC, and the old VC is then closed. If setup of the replacement VC fails, then the old QoS VC should continue to be used. When the new reservation is greater than the old reservation, the reservation request should be answered with an error. When the new reservation is less than the old reservation, the request should be treated as if the modification was successful. While leaving the larger allocation in place is suboptimal, it maximizes delivery of service to the user. Implementations should retry replacing the too large VC after some appropriate elapsed time.
支持RSVP保留更改的默认方法是尝试用新的适当大小的VC替换现有VC。在更换VC的设置过程中，旧VC必须保持原样。旧的VC保持不变，以尽量减少QoS数据传输的中断。一旦建立了替换VC，数据传输将转移到新VC，然后关闭旧VC。如果更换VC的设置失败，则应继续使用旧的QoS VC。当新预订大于旧预订时，预订请求应回答为错误。当新预订少于旧预订时，应将请求视为修改成功。虽然保留较大的分配是次优的，但它最大限度地向用户提供服务。在经过适当的时间后，实现应该重试替换过大的VC。
One additional issue is that only one QoS change can be processed at one time per reservation. If the (RSVP) requested QoS is changed while the first replacement VC is still being setup, then the replacement VC is released and the whole VC replacement process is restarted. To limit the number of changes and to avoid excessive signalling load, implementations may limit the number of changes that will be processed in a given period. One implementation approach would have each ATM edge device configured with a time parameter T (which can change over time) that gives the minimum amount of time the edge device will wait between successive changes of the QoS of a particular VC. Thus if the QoS of a VC is changed at time t, all messages that would change the QoS of that VC that arrive before time t+T would be queued. If several messages changing the QoS of a VC arrive during the interval, redundant messages can be discarded. At time t+T, the remaining change(s) of QoS, if any, can be executed. This timer approach would apply more generally to any network structure, and might be worthwhile to incorporate into RSVP.
另一个问题是，每个预订一次只能处理一个QoS更改。如果（RSVP）请求的QoS在第一个替换VC仍在设置时发生更改，则会释放替换VC并重新启动整个VC替换过程。为了限制更改的数量并避免过度的信令负载，实现可能会限制在给定时间段内处理的更改数量。一种实现方法将使每个ATM边缘设备配置一个时间参数T（可以随时间变化），该参数给出边缘设备在特定VC的QoS的连续变化之间等待的最小时间量。因此，如果VC的QoS在时间t改变，那么在时间t+t之前到达的所有改变VC QoS的消息都将排队。如果在这段时间间隔内有多条改变VC QoS的消息到达，则可以丢弃冗余消息。在时间t+t处，可以执行QoS的剩余变化（如果有的话）。这种计时器方法将更普遍地应用于任何网络结构，并且可能值得合并到RSVP中。
The sequence of events for a single VC would be
单个VC的事件顺序为
- Wait if timer is active - Establish VC with new QoS - Remap data traffic to new VC - Tear down old VC - Activate timer
- 如果计时器处于活动状态，请等待-使用新QoS建立VC-将数据流量重新映射到新VC-拆除旧VC-激活计时器
There is an interesting interaction between heterogeneous reservations and dynamic QoS. In the case where a RESV message is received from a new next-hop and the requested resources are larger than any existing reservation, both dynamic QoS and heterogeneity need to be addressed. A key issue is whether to first add the new next-hop or to change to the new QoS. This is a fairly straight forward special case. Since the older, smaller reservation does not support the new next-hop, the dynamic QoS process should be initiated first. Since the new QoS is only needed by the new next-hop, it should be the first end-point of the new VC. This way signalling is minimized when the setup to the new next-hop fails.
在异构保留和动态QoS之间有一个有趣的交互。在从新的下一跳接收RESV消息并且请求的资源大于任何现有保留的情况下，需要解决动态QoS和异构性。一个关键问题是，是首先添加新的下一跳，还是更改为新的QoS。这是一个相当直截了当的特例。由于较旧、较小的保留不支持新的下一跳，因此应首先启动动态QoS过程。由于新的QoS只需要新的下一跳，因此它应该是新VC的第一个端点。当新下一跳的设置失败时，这种方式可以最小化信令。
Short-cuts [4] allow ATM attached routers and hosts to directly establish point-to-point VCs across LIS boundaries, i.e., the VC end-points are on different IP subnets. The ability for short-cuts and RSVP to interoperate has been raised as a general question. An area of concern is the ability to handle asymmetric short-cuts. Specifically how RSVP can handle the case where a downstream short-cut may not have a matching upstream short-cut. In this case, PATH and RESV messages following different paths.
捷径[4]允许ATM连接的路由器和主机跨LIS边界直接建立点对点VCs，即VC端点位于不同的IP子网上。捷径和RSVP的互操作能力已作为一个普遍问题提出。一个值得关注的领域是处理不对称捷径的能力。具体而言，RSVP如何处理下游捷径可能没有匹配上游捷径的情况。在这种情况下，PATH和RESV消息遵循不同的路径。
Examination of RSVP shows that the protocol already includes mechanisms that will support short-cuts. The mechanism is the same one used to support RESV messages arriving at the wrong router and the wrong interface. The key aspect of this mechanism is RSVP only processing messages that arrive at the proper interface and RSVP forwarding of messages that arrive on the wrong interface. The proper interface is indicated in the NHOP object of the message. So, existing RSVP mechanisms will support asymmetric short-cuts. The short-cut model of VC establishment still poses several issues when running with RSVP. The major issues are dealing with established best-effort short-cuts, when to establish short-cuts, and QoS only short-cuts. These issues will need to be addressed by RSVP implementations.
对RSVP的检查表明，该协议已经包含了支持快捷方式的机制。该机制与用于支持到达错误路由器和错误接口的RESV消息的机制相同。该机制的关键方面是，仅RSVP处理到达正确接口的消息，以及RSVP转发到达错误接口的消息。消息的NHOP对象中指示了正确的接口。因此，现有的RSVP机制将支持非对称捷径。VC建立的捷径模型在与RSVP一起运行时仍然存在一些问题。主要问题是处理已建立的尽力而为的捷径、何时建立捷径以及仅QoS的捷径。这些问题需要通过RSVP实现来解决。
The key issue to be addressed by any RSVP over ATM solution is when to establish a short-cut for a QoS data flow. The default behavior is to simply follow best-effort traffic. When a short-cut has been
任何基于ATM的RSVP解决方案都要解决的关键问题是何时为QoS数据流建立一条捷径。默认行为是简单地遵循尽力而为的流量。当一条捷径被切断时
established for best-effort traffic to a destination or next-hop, that same end-point should be used when setting up RSVP triggered VCs for QoS traffic to the same destination or next-hop. This will happen naturally when PATH messages are forwarded over the best-effort short-cut. Note that in this approach when best-effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established. More study is expected in this area.
为到达目的地或下一跳的尽力而为流量而建立，在为到达同一目的地或下一跳的QoS流量设置RSVP触发的VCs时，应使用相同的端点。当路径消息通过尽力而为的捷径转发时，这将自然发生。注意，在这种方法中，当从未建立尽力而为的快捷方式时，也将永远不会建立RSVP触发的QoS快捷方式。在这方面还需要更多的研究。
RSVP can identify from either explicit messages or timeouts when a data VC is no longer needed. Therefore, data VCs set up to support RSVP controlled flows should only be released at the direction of RSVP. VCs must not be timed out due to inactivity by either the VC initiator or the VC receiver. This conflicts with VCs timing out as described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755 recommends tearing down a VC that is inactive for a certain length of time. Twenty minutes is recommended. This timeout is typically implemented at both the VC initiator and the VC receiver. Although, section 3.1 of the update to RFC 1755 [11] states that inactivity timers must not be used at the VC receiver.
当不再需要数据VC时，RSVP可以通过显式消息或超时来识别。因此，为支持RSVP控制流而设置的数据VCs只能在RSVP的指导下发布。VCs不得因VC启动器或VC接收器的不活动而超时。这与RFC 1755[11]第3.4节“VC拆卸”中所述的VCs超时相冲突。RFC 1755建议拆除在一定时间内处于非活动状态的VC。建议20分钟。此超时通常在VC启动器和VC接收器上实现。尽管如此，RFC 1755[11]更新的第3.1节规定，VC接收器不得使用非活动计时器。
When this timeout occurs for an RSVP initiated VC, a valid VC with QoS will be torn down unexpectedly. While this behavior is acceptable for best-effort traffic, it is important that RSVP controlled VCs not be torn down. If there is no choice about the VC being torn down, the RSVP daemon must be notified, so a reservation failure message can be sent.
当RSVP启动的VC发生此超时时，具有QoS的有效VC将意外被拆除。虽然这种行为对于尽力而为的流量是可以接受的，但RSVP控制的VCs不应被拆除是很重要的。如果无法选择拆除VC，则必须通知RSVP守护进程，以便发送保留失败消息。
For VCs initiated at the request of RSVP, the configurable inactivity timer mentioned in [11] must be set to "infinite". Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be relayed internally at the originator. Setting the inactivity timer at the VC receiver is more difficult, and would require some mechanism to signal that an incoming VC was RSVP initiated. To avoid this complexity and to conform to [11] implementations must not use an inactivity timer to clear received connections.
对于应RSVP请求启动的VCs，[11]中提到的可配置非活动计时器必须设置为“无限”。在VC启动器上设置非活动计时器值应该没有问题，因为正确的值可以在启动器内部中继。在VC接收器上设置非活动计时器更为困难，需要某种机制来发出信号，表明传入的VC是RSVP启动的。为了避免这种复杂性并符合[11]的要求，实现不得使用非活动计时器清除接收到的连接。
One last important issue is providing a data path for the RSVP messages themselves. There are two main types of messages in RSVP, PATH and RESV. PATH messages are sent to unicast or multicast addresses, while RESV messages are sent only to unicast addresses. Other RSVP messages are handled similar to either PATH or RESV, although this might be more complicated for RERR messages. So ATM VCs used for RSVP signalling messages need to provide both unicast
最后一个重要问题是为RSVP消息本身提供数据路径。RSVP中有两种主要的消息类型：PATH和RESV。PATH消息发送到单播或多播地址，而RESV消息仅发送到单播地址。其他RSVP消息的处理方式与PATH或RESV类似，尽管这对于RERR消息可能更复杂。因此，用于RSVP信令消息的ATM VCs需要提供单播和
and multicast functionality. There are several different approaches for how to assign VCs to use for RSVP signalling messages.
和多播功能。对于如何为RSVP信令消息分配VCs，有几种不同的方法。
The main approaches are:
主要方法是：
- use same VC as data - single VC per session - single point-to-multipoint VC multiplexed among sessions - multiple point-to-point VCs multiplexed among sessions
- 使用与数据相同的VC-每个会话使用一个VC-会话间多路复用的单点到多点VC-会话间多路复用的多个点到点VC
There are several different issues that affect the choice of how to assign VCs for RSVP signalling. One issue is the number of additional VCs needed for RSVP signalling. Related to this issue is the degree of multiplexing on the RSVP VCs. In general more multiplexing means fewer VCs. An additional issue is the latency in dynamically setting up new RSVP signalling VCs. A final issue is complexity of implementation. The remainder of this section discusses the issues and tradeoffs among these different approaches and suggests guidelines for when to use which alternative.
有几个不同的问题影响如何为RSVP信令分配VCs的选择。一个问题是RSVP信令所需的额外VCs的数量。与此问题相关的是RSVP VCs上的多路复用程度。一般来说，更多的多路复用意味着更少的VCs。另一个问题是动态设置新RSVP信令VCs的延迟。最后一个问题是实现的复杂性。本节的其余部分将讨论这些不同方法之间的问题和权衡，并建议何时使用哪种方法。
In this scheme RSVP signalling messages are sent on the same VCs as is the data traffic. The main advantage of this scheme is that no additional VCs are needed beyond what is needed for the data traffic. An additional advantage is that there is no ATM signalling latency for PATH messages (which follow the same routing as the data messages). However there can be a major problem when data traffic on a VC is nonconforming. With nonconforming traffic, RSVP signalling messages may be dropped. While RSVP is resilient to a moderate level of dropped messages, excessive drops would lead to repeated tearing down and re-establishing of QoS VCs, a very undesirable behavior for ATM. Due to these problems, this may not be a good choice for providing RSVP signalling messages, even though the number of VCs needed for this scheme is minimized. One variation of this scheme is to use the best effort data path for signalling traffic. In this scheme, there is no issue with nonconforming traffic, but there is an issue with congestion in the ATM network. RSVP provides some resiliency to message loss due to congestion, but RSVP control messages should be offered a preferred class of service. A related variation of this scheme that is hopeful but requires further study is to have a packet scheduling algorithm (before entering the ATM network) that gives priority to the RSVP signalling traffic. This can be difficult to do at the IP layer.
在该方案中，RSVP信令消息在与数据通信相同的VCs上发送。该方案的主要优点是，除了数据流量所需的VCs之外，不需要额外的VCs。另一个优点是路径消息（遵循与数据消息相同的路由）没有ATM信令延迟。然而，当VC上的数据流量不符合要求时，可能会出现一个主要问题。对于不符合要求的通信量，RSVP信令消息可能会被丢弃。虽然RSVP对中等程度的丢弃消息具有弹性，但过多的丢弃会导致QoS VCs的重复拆除和重新建立，这对于ATM来说是非常不可取的行为。由于这些问题，这可能不是提供RSVP信令消息的好选择，即使该方案所需的VCs数量最小化。该方案的一个变体是使用尽力而为的数据路径来发送业务。在该方案中，不存在非一致流量的问题，但存在ATM网络拥塞的问题。RSVP为拥塞导致的消息丢失提供了一定的恢复能力，但RSVP控制消息应提供首选服务类别。该方案的一个相关变化是（在进入ATM网络之前）有一个分组调度算法，该算法优先考虑RSVP信令流量，这是有希望但需要进一步研究的。这在IP层很难做到。
In this scheme, there is a parallel RSVP signalling VC for each RSVP reservation. This scheme results in twice the number of VCs, but means that RSVP signalling messages have the advantage of a separate VC. This separate VC means that RSVP signalling messages have their own traffic contract and compliant signalling messages are not subject to dropping due to other noncompliant traffic (such as can happen with the scheme in section 4.3.1). The advantage of this scheme is its simplicity - whenever a data VC is created, a separate RSVP signalling VC is created. The disadvantage of the extra VC is that extra ATM signalling needs to be done. Additionally, this scheme requires twice the minimum number of VCs and also additional latency, but is quite simple.
在该方案中，每个RSVP预留都有一个并行RSVP信令VC。此方案导致VCs数量增加一倍，但意味着RSVP信令消息具有单独VC的优势。这一单独的VC意味着RSVP信令消息有其自己的通信协议，并且兼容信令消息不会由于其他不兼容通信而被丢弃（如第4.3.1节中的方案可能发生的情况）。该方案的优点是其简单性——无论何时创建数据VC，都会创建单独的RSVP信令VC。额外VC的缺点是需要执行额外的ATM信令。此外，此方案需要两倍于最小VCs数量的VCs和额外的延迟，但非常简单。
In this scheme, there is a single point-to-multipoint RSVP signalling VC for each unique ingress router and unique set of egress routers. This scheme allows multiplexing of RSVP signalling traffic that shares the same ingress router and the same egress routers. This can save on the number of VCs, by multiplexing, but there are problems when the destinations of the multiplexed point-to-multipoint VCs are changing. Several alternatives exist in these cases, that have applicability in different situations. First, when the egress routers change, the ingress router can check if it already has a point-to-multipoint RSVP signalling VC for the new list of egress routers. If the RSVP signalling VC already exists, then the RSVP signalling traffic can be switched to this existing VC. If no such VC exists, one approach would be to create a new VC with the new list of egress routers. Other approaches include modifying the existing VC to add an egress router or using a separate new VC for the new egress routers. When a destination drops out of a group, an alternative would be to keep sending to the existing VC even though some traffic is wasted. The number of VCs used in this scheme is a function of traffic patterns across the ATM network, but is always less than the number used with the Single RSVP VC per data VC. In addition, existing best effort data VCs could be used for RSVP signalling. Reusing best effort VCs saves on the number of VCs at the cost of higher probability of RSVP signalling packet loss. One possible place where this scheme will work well is in the core of the network where there is the most opportunity to take advantage of the savings due to multiplexing. The exact savings depend on the patterns of traffic and the topology of the ATM network.
在该方案中，每个唯一的入口路由器和唯一的出口路由器组都有一个单点到多点RSVP信令VC。该方案允许共享同一入口路由器和同一出口路由器的RSVP信令流量的复用。这可以通过多路复用节省VCs的数量，但当多路复用的点对多点VCs的目的地发生变化时，会出现问题。在这些情况下，存在几种备选方案，它们适用于不同的情况。首先，当出口路由器改变时，入口路由器可以检查它是否已经具有用于新出口路由器列表的点对多点RSVP信令VC。如果RSVP信令VC已经存在，则RSVP信令业务可以切换到此现有VC。如果不存在这样的VC，一种方法是使用新的出口路由器列表创建一个新的VC。其他方法包括修改现有VC以添加出口路由器或为新出口路由器使用单独的新VC。当一个目的地从组中退出时，另一种选择是即使浪费了一些通信量也要继续发送到现有的VC。此方案中使用的VCs数量是ATM网络中流量模式的函数，但始终小于每个数据VC使用的单个RSVP VC的数量。此外，现有尽力而为的数据VCs可用于RSVP信令。重用尽力而为的VCs可以节省VCs的数量，但代价是RSVP信令分组丢失的概率更高。这一方案可以很好地发挥作用的一个可能的地方是网络的核心，在那里有最多的机会利用多路复用带来的节约。确切的节约取决于流量模式和ATM网络的拓扑结构。
In this scheme, multiple point-to-point RSVP signalling VCs are used for a single point-to-multipoint data VC. This scheme allows multiplexing of RSVP signalling traffic but requires the same traffic to be sent on each of several VCs. This scheme is quite flexible and allows a large amount of multiplexing.
在该方案中，多个点对点RSVP信令VC用于单点对多点数据VC。该方案允许RSVP信令业务的多路复用，但要求在多个VCs中的每个VCs上发送相同的业务。该方案非常灵活，允许大量多路复用。
Since point-to-point VCs can set up a reverse channel at the same time as setting up the forward channel, this scheme could save substantially on signalling cost. In addition, signalling traffic could share existing best effort VCs. Sharing existing best effort VCs reduces the total number of VCs needed, but might cause signalling traffic drops if there is congestion in the ATM network. This point-to-point scheme would work well in the core of the network where there is much opportunity for multiplexing. Also in the core of the network, RSVP VCs can stay permanently established either as Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual Circuits (SVCs). The number of VCs in this scheme will depend on traffic patterns, but in the core of a network would be approximately n(n-1)/2 where n is the number of IP nodes in the network. In the core of the network, this will typically be small compared to the total number of VCs.
由于点对点VCs可以在建立前向信道的同时建立反向信道，因此该方案可以大大节省信令成本。此外，信令业务可以共享现有的尽力而为的VCs。共享现有尽力而为的VCs可减少所需VCs的总数，但如果ATM网络出现拥塞，则可能会导致信令流量下降。这种点对点方案将在网络的核心中很好地工作，因为那里有很多多路复用的机会。同样在网络的核心，RSVP VCs可以作为永久虚拟电路（PVC）或长寿命交换虚拟电路（SVC）永久建立。此方案中的VCs数量将取决于流量模式，但网络核心中的VCs数量约为n（n-1）/2，其中n是网络中IP节点的数量。在网络的核心，这通常比VCs的总数要小。
There is an issue of what QoS, if any, to assign to the RSVP signalling VCs. For other RSVP VC schemes, a QoS (possibly best effort) will be needed. What QoS to use partially depends on the expected level of multiplexing that is being done on the VCs, and the expected reliability of best effort VCs. Since RSVP signalling is infrequent (typically every 30 seconds), only a relatively small QoS should be needed. This is important since using a larger QoS risks the VC setup being rejected for lack of resources. Falling back to best effort when a QoS call is rejected is possible, but if the ATM net is congested, there will likely be problems with RSVP packet loss on the best effort VC also. Additional experimentation is needed in this area.
存在向RSVP信令VCs分配什么QoS（如果有）的问题。对于其他RSVP VC方案，需要QoS（可能是最大努力）。使用什么QoS部分取决于VCs上正在进行的预期多路复用级别，以及尽力而为VCs的预期可靠性。由于RSVP信令很少（通常每30秒一次），因此只需要相对较小的QoS。这一点很重要，因为使用更大的QoS可能会导致VC设置因资源不足而被拒绝。当QoS呼叫被拒绝时，返回到最大努力是可能的，但是如果ATM网络拥塞，则在最大努力VC上也可能存在RSVP数据包丢失问题。这方面还需要更多的实验。
Since RSVP is a signalling protocol used to control flows of IP data packets, encapsulation for both RSVP packets and associated IP data packets must be defined. The methods for transmitting IP packets over ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based on the encapsulations defined in RFC1483 [19]. RFC1483 specifies two encapsulations, LLC Encapsulation and VC-based multiplexing. The former allows multiple protocols to be encapsulated over the same VC
由于RSVP是用于控制IP数据包流的信令协议，因此必须定义RSVP数据包和相关IP数据包的封装。通过ATM传输IP数据包的方法（ATM上的经典IP[10]、LANE[17]和MPOA[18]）都基于RFC1483[19]中定义的封装。RFC1483指定了两种封装，LLC封装和基于VC的多路复用。前者允许在同一个VC上封装多个协议
and the latter requires different VCs for different protocols.
后者需要不同协议的不同VCs。
For the purposes of RSVP over ATM, any encapsulation can be used as long as the VCs are managed in accordance to the methods outlined in Section 4. Obviously, running multiple protocol data streams over the same VC with LLC encapsulation can cause the same problems as running multiple flows over the same VC.
就ATM上的RSVP而言，只要按照第4节中概述的方法管理VCs，就可以使用任何封装。显然，使用LLC封装在同一个VC上运行多个协议数据流可能会导致与在同一个VC上运行多个流相同的问题。
While none of the transmission methods directly address the issue of QoS, RFC1755 [11] does suggest some common values for VC setup for best-effort traffic. [14] discusses the relationship of the RFC1755 setup parameters and those needed to support IntServ flows in greater detail.
虽然没有一种传输方法直接解决QoS问题，但RFC1755[11]确实为尽最大努力流量的VC设置建议了一些通用值。[14] 详细讨论RFC1755设置参数与支持IntServ流所需参数之间的关系。
The same considerations stated in [1] and [11] apply to this document. There are no additional security issues raised in this document.
[1]和[11]中所述的注意事项同样适用于本文件。本文档中没有提出其他安全问题。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2209, September 1997.
[1] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 2209，1997年9月。
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Realtime Services in an IP-ATM Network Architecture", RFC 1821, August 1995.
[2] Borden，M.，Crawley，E.，Davie，B.，和S.Batsell，“IP-ATM网络架构中的实时服务集成”，RFC 18211995年8月。
[3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", RFC 1932, April 1996.
[3] Cole，R.，Shur，D.，和C.Villamizar，“ATM上的IP：框架文件”，RFC 1932，1996年4月。
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[4] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.，和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[5] Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[6] Shenker, S., and C. Partridge, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[6] Shenker，S.和C.Partridge，“保证服务质量规范”，RFC 2212，1997年9月。
[7] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[7] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[8] ATM Forum. ATM User-Network Interface Specification Version 3.0. Prentice Hall, September 1993.
[8] ATM论坛。ATM用户网络接口规范3.0版。普伦蒂斯大厅，1993年9月。
[9] ATM Forum. ATM User Network Interface (UNI) Specification Version 3.1. Prentice Hall, June 1995.
[9] ATM论坛。ATM用户网络接口（UNI）规范版本3.1。普伦蒂斯大厅，1995年6月。
[10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[10] Laubach，M.，“ATM上的经典IP和ARP”，RFC2225，1998年4月。
[11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[11] Perez，M.，Mankin，A.，Hoffman，E.，Grossman，G.，和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[12] Herzog, S., "RSVP Extensions for Policy Control", Work in Progress.
[12] Herzog，S.，“策略控制的RSVP扩展”，正在进行中。
[13] Herzog, S., "Local Policy Modules (LPM): Policy Control for RSVP", Work in Progress.
[13] Herzog，S.，“本地策略模块（LPM）：RSVP的策略控制”，正在进行中。
[14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load and Guaranteed Service with ATM", RFC 2381, August 1998.
[14] Borden，M.和M.Garrett，“受控负载和保证服务与ATM的互操作”，RFC 2381，1998年8月。
[15] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[15] Berger，L.“ATM上的RSVP实施要求”，RFC 2380，1998年8月。
[16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379, August 1998.
[16] Berger，L.，“ATM上的RSVP实施指南”，RFC 2379，1998年8月。
[17] ATM Forum Technical Committee. LAN Emulation over ATM, Version 1.0 Specification, af-lane-0021.000, January 1995.
[17] ATM论坛技术委员会。ATM上的局域网仿真，1.0版规范，af-lane-0021.000，1995年1月。
[18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95- 0824r9, September 1996.
[18] ATM论坛技术委员会。MPOA的基线文本，af-95-0824r9，1996年9月。
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[19] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2 - LUNI Specification, December 1996.
[20] ATM论坛技术委员会。ATM版本2上的局域网仿真-LUNI规范，1996年12月。
[21] ATM Forum Technical Committee. Traffic Management Specification v4.0, af-tm-0056.000, April 1996.
[21] ATM论坛技术委员会。交通管理规范v4.0，af-tm-0056.000，1996年4月。
[22] Callon, R., et al., "A Framework for Multiprotocol Label Switching, Work in Progress.
[22] Callon，R.，等人，“多协议标签交换框架，正在进行中。
[23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[23] Rajagopalan，B.，Nair，R.，Sandick，H.，和E.Crawley，“互联网中基于QoS的路由框架”，RFC 2386，1998年8月。
[24] ITU-T. Digital Subscriber Signaling System No. 2-Connection modification: Peak cell rate modification by the connection owner, ITU-T Recommendation Q.2963.1, July 1996.
[24] ITU-T.《数字用户信令系统第2号——连接修改：由连接所有者修改峰值信元速率》，ITU-T建议Q.2963.11996年7月。
[25] ITU-T. Digital Subscriber Signaling System No. 2-Connection characteristics negotiation during call/connection establishment phase, ITU-T Recommendation Q.2962, July 1996.
[25] ITU-T.《数字用户信令系统第2号——呼叫/连接建立阶段的连接特性协商》，ITU-T建议Q.2962，1996年7月。
[26] ATM Forum Technical Committee. Private Network-Network Interface Specification v1.0 (PNNI), March 1996.
[26] ATM论坛技术委员会。专用网络接口规范v1.0（PNNI），1996年3月。
Eric S. Crawley Argon Networks 25 Porter Road Littleton, Ma 01460
马萨诸塞州利特尔顿波特路25号Eric S.Crawley Argon Networks邮编01460
Phone: +1 978 486-0665
EMail: esc@argon.com
Phone: +1 978 486-0665
EMail: esc@argon.com
Lou Berger FORE Systems 6905 Rockledge Drive Suite 800 Bethesda, MD 20817
Lou Berger FORE Systems 6905 Rockledge Drive Suite 800马里兰州贝塞斯达20817
Phone: +1 301 571-2534
EMail: lberger@fore.com
Phone: +1 301 571-2534
EMail: lberger@fore.com
Steven Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Steven Berson南加州信息科学研究所，地址：加利福尼亚州玛丽娜·德雷市金钟路4676号，邮编：90292
Phone: +1 310 822-1511
EMail: berson@isi.edu
Phone: +1 310 822-1511
EMail: berson@isi.edu
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara，加利福尼亚93111
Phone: +1 805 681-0115
EMail: fred@cisco.com
Phone: +1 805 681-0115
EMail: fred@cisco.com
Marty Borden Bay Networks 125 Nagog Park Acton, MA 01720
马蒂波登湾网络125纳戈公园阿克顿，马萨诸塞州01720
Phone: +1 978 266-1011
EMail: mborden@baynetworks.com
Phone: +1 978 266-1011
EMail: mborden@baynetworks.com
John J. Krawczyk ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886
马萨诸塞州利特尔顿路西福235号约翰·J·克劳茨克·阿罗波因特通信公司，邮编：01886
Phone: +1 978 692-5875
EMail: jj@arrowpoint.com
Phone: +1 978 692-5875
EMail: jj@arrowpoint.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。