Network Working Group L. Berger
Request for Comments: 2380 FORE Systems
Category: Standards Track August 1998
Network Working Group L. Berger
Request for Comments: 2380 FORE Systems
Category: Standards Track August 1998
RSVP over ATM Implementation Requirements
ATM上的RSVP实施要求
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.
本备忘录介绍了在ATM交换虚拟电路（SVC）上运行RSVP的具体实施要求。它提出了确保多个实现之间的互操作性以及符合RSVP和集成服务规范的要求。另一份文件[5]提供了在当今ATM网络上运行的具体指南。一般问题在[9]中讨论。[6]中介绍了综合服务到ATM服务的映射。全套文件介绍了在ATM上实施综合业务和RSVP所需的背景和信息。
Table of Contents
目录
1. Introduction ................................................. 2
1.1 Terms .................................................... 2
1.2 Assumptions .............................................. 3
2. General RSVP Session Support ................................. 4
2.1 RSVP Message VC Usage .................................... 4
2.2 VC Initiation ............................................ 4
2.3 VC Teardown .............................................. 5
2.4 Dynamic QoS .............................................. 6
2.5 Encapsulation ............................................ 6
3. Multicast RSVP Session Support ............................... 7
3.1 Data VC Management for Heterogeneous Sessions ............ 7
3.2 Multicast End-Point Identification ....................... 8
3.3 Multicast Data Distribution .............................. 9
3.4 Receiver Transitions ..................................... 11
1. Introduction ................................................. 2
1.1 Terms .................................................... 2
1.2 Assumptions .............................................. 3
2. General RSVP Session Support ................................. 4
2.1 RSVP Message VC Usage .................................... 4
2.2 VC Initiation ............................................ 4
2.3 VC Teardown .............................................. 5
2.4 Dynamic QoS .............................................. 6
2.5 Encapsulation ............................................ 6
3. Multicast RSVP Session Support ............................... 7
3.1 Data VC Management for Heterogeneous Sessions ............ 7
3.2 Multicast End-Point Identification ....................... 8
3.3 Multicast Data Distribution .............................. 9
3.4 Receiver Transitions ..................................... 11
4. Security Considerations ...................................... 11
5. Acknowledgments .............................................. 11
6. Author's Address ............................................. 12
REFERENCES ...................................................... 13
FULL COPYRIGHT STATEMENT ........................................ 14
4. Security Considerations ...................................... 11
5. Acknowledgments .............................................. 11
6. Author's Address ............................................. 12
REFERENCES ...................................................... 13
FULL COPYRIGHT STATEMENT ........................................ 14
This memo discusses running IP over ATM in an environment where SVCs are used to support QoS flows and RSVP is used as the internet level QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and MPOA [4] methods for supporting IP over ATM. The general issues related to running RSVP [8] over ATM have been covered in several papers including [9] and other earlier work. This document is intended as a companion to [9,5]. The reader should be familiar with both documents.
本备忘录讨论了在使用SVC支持QoS流且使用RSVP作为internet级QoS信令协议的环境中通过ATM运行IP。它适用于使用CLIP/ION、LANE2.0和MPOA[4]方法支持ATM上的IP时。与在ATM上运行RSVP[8]相关的一般问题已经在几篇论文中讨论过，包括[9]和其他早期工作。本文件旨在作为[9,5]的配套文件。读者应熟悉这两个文件。
This document defines the specific requirements for implementations using ATM UNI3.x and 4.0. These requirements must be adhered to by all RSVP over ATM implementations to ensure interoperability. Further recommendations to guide implementers of RSVP over ATM are provided in [5].
本文件定义了使用ATM UNI3.x和4.0实现的具体要求。所有RSVP over ATM实施必须遵守这些要求，以确保互操作性。[5]中提供了指导ATM上RSVP实施者的进一步建议。
The rest of this section will define terms and assumptions. Section 2 will cover implementation guidelines common to all RSVP session. Section 3 will cover implementation guidelines specific to multicast sessions.
本节其余部分将定义术语和假设。第2节将涵盖所有RSVP会议通用的实施指南。第3节将介绍特定于多播会话的实施指南。
The terms "reservation" and "flow" are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
“保留”和“流动”这两个术语在许多上下文中使用，通常含义不同。本文件中使用的这些术语具有以下含义：
o 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 [8] for details of each. Each new request is referred to in this document as an RSVP reservation, or simply reservation.
o 本文档中的保留用于指RSVP发起的资源请求。RSVP根据RESV消息处理启动资源请求。仅刷新状态的RESV消息不会触发资源请求。资源请求可以基于RSVP会话和RSVP保留样式进行。RSVP样式决定保留资源是由一个发件人使用还是由多个发件人共享。有关每种方法的详细信息，请参见[8]。在本文档中，每个新请求都称为RSVP保留，或简称为保留。
o 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).
o 流用于引用与特定保留相关联的数据通信量。流的具体含义取决于RSVP样式。对于共享样式保留，每个会话有一个流。对于不同样式的保留，每个发送者（每个会话）有一个流。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
The following assumptions are made:
作出以下假设：
o RSVP
o 冒险类游戏
We assume RSVP as the internet signaling protocol which is described in [8]. The reader is assumed to be familiar with [8].
我们假设RSVP是互联网信令协议，如[8]所述。假定读者熟悉[8]。
o IPv4 and IPv6
o IPv4和IPv6
RSVP support has been defined for both IPv4 and IPv6. The guidelines in this document are intended to be used to support RSVP with either IPv4 or IPv6. This document does not require one version over the other.
已为IPv4和IPv6定义了RSVP支持。本文档中的指南旨在支持IPv4或IPv6的RSVP。本文件不要求一个版本优于另一个版本。
o Best effort service model
o 尽力而为服务模式
The current Internet only supports best effort service. We assume that as additional components of the Integrated Services model are defined, best effort service must continue to be supported.
目前的互联网只支持尽力而为的服务。我们假设，随着集成服务模型的其他组件的定义，必须继续支持尽力而为的服务。
o ATM UNI 3.x and 4.0
o ATM UNI 3.x和4.0
We assume ATM service as defined by UNI 3.x and 4.0. ATM provides both point-to-point and point-to-multipoint Virtual Circuits (VCs) with a specified Quality of Service (QoS). ATM provides both Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). In the Permanent Virtual Circuit (PVC) environment, PVCs are typically used as point-to-point link replacements. So the support issues are similar to point-to-point links. This memo assumes that SVCs are used to support RSVP over ATM.
我们假设ATM服务符合UNI 3.x和4.0的定义。ATM提供具有特定服务质量（QoS）的点对点和点对多点虚拟电路（VCs）。ATM提供永久虚拟电路（PVC）和交换虚拟电路（SVC）。在永久虚拟电路（PVC）环境中，PVC通常用作点对点链路替换。因此，支持问题类似于点对点链接。本备忘录假设SVC用于支持ATM上的RSVP。
This section provides implementation requirements that are common for all (both unicast and multicast) RSVP sessions. The section covers VC usage, QoS VC initiation, VC teardown, handling requested changes in QoS, and encapsulation.
本节提供了所有（单播和多播）RSVP会话的通用实现要求。本节介绍VC使用、QoS VC启动、VC拆卸、处理请求的QoS更改以及封装。
There are several RSVP Message VC Usage options available to implementers. Implementers must select which VC to use for RSVP messages and how to aggregate RSVP sessions over QoS VCs. These options have been covered in [9] and some specific implementation guidelines are stated in [5]. In order to ensure interoperability between implementations that follow different options, RSVP over ATM implementations MUST NOT send RSVP (control) messages on the same QoS VC as RSVP associated data packets. RSVP over ATM implementations MAY send RSVP messages on either the best effort data path or on a separate control VC.
有几个RSVP消息VC使用选项可供实现者使用。实现者必须选择用于RSVP消息的VC，以及如何通过QoS VCs聚合RSVP会话。[9]中介绍了这些选项，而[5]中阐述了一些具体的实施指南。为了确保遵循不同选项的实现之间的互操作性，ATM上的RSVP实现不得在与RSVP相关的数据包相同的QoS VC上发送RSVP（控制）消息。ATM上的RSVP实现可以在尽力而为的数据路径或单独的控制路径上发送RSVP消息。
Since RSVP (control) messages and RSVP associated data packets are not sent on the same VCs, it is possible for a VC supporting one type of traffic to fail while the other remains in place. When the VC associated with data packets fails and cannot be reestablished, RSVP SHOULD treat this as an allocation failure. When the VC used to forward RSVP control messages is abnormally released and cannot be reestablished, the RSVP associated QoS VCs MUST also be released. The release of the associated data VCs is required to maintain the synchronization between forwarding and reservation states for the associated data flows.
由于RSVP（控制）消息和与RSVP相关的数据包不是在同一个VCs上发送的，因此支持一种类型通信的VC可能会失败，而另一种类型的通信保持不变。当与数据包关联的VC失败且无法重新建立时，RSVP应将其视为分配失败。当用于转发RSVP控制消息的VC异常释放且无法重新建立时，还必须释放与RSVP相关的QoS VC。需要释放相关数据VCs，以保持相关数据流的转发和保留状态之间的同步。
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.
RSVP和ATM之间存在明显的不匹配。具体来说，RSVP控制面向接收方，ATM控制面向发送方。这一点起初似乎是一个主要问题，但实际上并非如此。当RSVP保留（RESV）请求在接收方生成时，资源的实际分配在子网发送方进行。
For data flows, this means that subnet senders MUST establish all QoS VCs and the RSVP enabled subnet receiver MUST be able to accept incoming QoS VCs. 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 interoperability problems. All RSVP over ATM approaches that have VCs initiated and controlled by the subnet senders will interoperate. Figure 1 shows this model of data flow VC initiation.
对于数据流，这意味着子网发送方必须建立所有QoS VCs，并且启用RSVP的子网接收方必须能够接受传入的QoS VCs。这些限制与RSVP版本1处理规则一致，允许发送方使用不同的流到VC映射，甚至使用不同的QoS重新协商技术，而不会出现互操作性问题。所有由子网发送方发起和控制VCs的RSVP over ATM方法将进行互操作。图1显示了数据流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初始化
RSVP over ATM implementations MAY send data in the backwards direction on an RSVP initiated QoS point-to-point VC. When sending in the backwards data path, the sender MUST ensure that the data conforms to the backwards direction traffic parameters. Since the traffic parameters are set by the VC initiator, it is quite likely that no resources will be requested for traffic originating at the called party. It should be noted that the backwards data path is not available with point-to-multipoint VCs.
ATM上的RSVP实现可以在RSVP发起的QoS点对点VC上向后发送数据。在向后数据路径中发送时，发送方必须确保数据符合向后方向流量参数。由于流量参数是由VC启动器设置的，因此很可能不会为发起于被叫方的流量请求任何资源。应注意的是，向后数据路径不适用于点对多点VCs。
VCs supporting IP over ATM data are typically torndown based on inactivity timers. This mechanism is used since IP is connectionless and there is therefore no way to know when a VC is no longer needed. Since RSVP provides explicit mechanisms (messages and timeouts) to determine when an associated data VC is no longer needed, the traditional VC timeout mechanisms are not needed. Additionally, under normal operations RSVP implementations expect to be able to allocate resources and have those resources remain allocated until released at the direction of RSVP. Therefore, data VCs set up to support RSVP controlled flows should only be released at the direction of RSVP. Such 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 [12] states that inactivity timers must not be used at the VC receiver.
支持IP over ATM数据的VCs通常基于非活动计时器关闭。使用这种机制是因为IP是无连接的，因此无法知道何时不再需要VC。由于RSVP提供了明确的机制（消息和超时）来确定何时不再需要关联的数据VC，因此不需要传统的VC超时机制。此外，在正常操作下，RSVP实现希望能够分配资源，并在RSVP的指示下释放之前保持这些资源的分配。因此，为支持RSVP控制流而设置的数据VCs只能在RSVP的指导下发布。此类VCs不得因VC启动器或VC接收器的不活动而超时。这与RFC 1755[11]第3.4节“VC拆卸”中所述的VCs超时相冲突。RFC 1755建议拆除在一定时间内处于非活动状态的VC。建议20分钟。此超时通常在VC启动器和VC接收器上实现。尽管如此，RFC 1755[12]更新的第3.1节规定，VC接收器不得使用非活动计时器。
In RSVP over ATM implementations, the configurable inactivity timer mentioned in [11] MUST be set to "infinite" for VCs initiated at the request of RSVP. Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be
在ATM上的RSVP实现中，[11]中提到的可配置非活动计时器必须设置为“无限”，用于应RSVP请求启动的VCs。在VC启动器上设置非活动计时器值应该没有问题，因为可以选择正确的值
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 [12], RSVP over ATM implementations MUST not use an inactivity timer to clear any received connections.
在发起人处进行内部中继。在VC接收器上设置非活动计时器更为困难，需要某种机制来发出信号，表明传入的VC是RSVP启动的。为了避免这种复杂性并符合[12]，ATM上的RSVP实现不得使用非活动计时器清除任何接收到的连接。
As stated in [9], there is a mismatch in the service provided by RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows modifications to QoS parameters at any time while ATM does not support any modifications to QoS parameters post VC setup. See [9] for more detail.
如[9]所述，RSVP提供的服务与ATM UNI3.x和4.0提供的服务不匹配。RSVP允许在任何时候修改QoS参数，而ATM不支持在VC设置后修改QoS参数。有关更多详细信息，请参见[9]。
The 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 only then is the old VC closed.
支持RSVP保留更改的方法是尝试用新的适当大小的VC替换现有VC。在更换VC的设置过程中，旧VC必须保持原样。旧的VC保持不变，以尽量减少QoS数据传输的中断。一旦建立了替换VC，数据传输将转移到新VC，只有在那时旧VC才会关闭。
If setup of the replacement VC fails, then the old QoS VC MUST continue to be used. When the new reservation is greater than the old reservation, the reservation request MUST be answered with an error. When the new reservation is less than the old reservation, the request MUST 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. The behavior is also required in order to conform to RSVP error handling as defined in sections 2.5, 3.1.8 and 3.11.2 of [8]. Implementations SHOULD retry replacing a too large VC after some appropriate elapsed time.
如果更换VC的设置失败，则必须继续使用旧的QoS VC。当新预订大于旧预订时，必须用错误回答预订请求。当新预订少于旧预订时，必须将请求视为修改成功。虽然保留较大的分配是次优的，但它最大限度地向用户提供服务。为了符合[8]第2.5节、第3.1.8节和第3.11.2节中定义的RSVP错误处理，还需要该行为。在经过适当的时间后，实现应该重新尝试替换过大的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 SHOULD BE released and the whole VC replacement process is restarted. Implementations MAY also limit number of changes processed in a time period per [9].
另一个问题是，每个预订一次只能处理一个QoS更改。如果（RSVP）请求的QoS在第一个替换VC仍在设置时发生更改，则应释放替换VC，并重新启动整个VC替换过程。实现还可以限制每个[9]在一个时间段内处理的更改数量。
There are multiple encapsulation options for data sent over RSVP triggered QoS VCs. All RSVP over ATM implementations MUST be able to support LLC encapsulation per RFC 1483 [10] on such QoS VCs. Implementations MAY negotiate alternative encapsulations using the B-LLI negotiation procedures defined in ATM Signalling, see [11] for
通过RSVP触发的QoS VCs发送的数据有多个封装选项。ATM上的所有RSVP实现必须能够在此类QoS VCs上按照RFC 1483[10]支持LLC封装。实现可以使用ATM信令中定义的B-LLI协商过程协商替代封装，有关详细信息，请参见[11]
details. When a QoS VC is only being used to carry IP packets, implementations SHOULD negotiate VC based multiplexing to avoid incurring the overhead of the LLC header.
细节。当QoS VC仅用于承载IP数据包时，实现应协商基于VC的多路复用，以避免产生LLC报头的开销。
There are several aspects to running RSVP over ATM that are unique to multicast sessions. This section addresses multicast end-point identification, multicast data distribution, multicast receiver transitions and next-hops requesting different QoS values (heterogeneity) which includes the handling of multicast best effort receivers. Handling of best effort receivers is not strictly an RSVP issue, but needs to be addressed by any RSVP over ATM implementation in order to maintain expected best effort internet service.
在ATM上运行RSVP有几个方面是多播会话所特有的。本节讨论多播端点标识、多播数据分布、多播接收器转换和请求不同QoS值（异构性）的下一跳，其中包括多播尽力而为接收器的处理。尽力而为接收器的处理并非严格意义上的RSVP问题，但需要通过ATM上的任何RSVP实现来解决，以维持预期的尽力而为互联网服务。
The issues relating to data VC management of heterogeneous sessions are covered in detail in [9]. In summary, heterogeneity occurs when receivers request different levels of QoS within a single session, and also when some receivers do not request any QoS. Both types of heterogeneity are shown in figure 2.
[9]详细介绍了与异构会话的数据管理相关的问题。总之，当接收器在单个会话中请求不同级别的QoS时，以及当一些接收器不请求任何QoS时，就会出现异构性。两种类型的异质性如图2所示。
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
Figure 2: Types of Multicast Receivers
图2：多播接收器的类型
[9] provides four models for dealing with heterogeneity: full heterogeneity, limited heterogeneity, homogeneous, and modified homogeneous models. No matter which model or combination of models is used by an implementation, implementations MUST NOT normally send
[9] 提供四种处理异质性的模型：完全异质性、有限异质性、同质性和修改的同质性模型。无论实现使用哪种模型或模型组合，实现通常都不能发送
more than one copy of a particular data packet to a particular next-hop (ATM end-point). Some transient duplicate transmission is acceptable, but only during VC setup and transition.
将特定数据包的多个副本发送到特定下一跳（ATM端点）。一些瞬态复制传输是可以接受的，但仅在VC设置和转换期间。
Implementations MUST also ensure that data traffic is sent to best effort receivers. Data traffic MAY be sent to best effort receivers via best effort or QoS VCs as is appropriate for the implemented model. In all cases, implementations MUST NOT create VCs in such a way that data cannot be sent to best effort receivers. This includes the case of not being able to add a best effort receiver to a QoS VC, but does not include the case where best effort VCs cannot be setup. The failure to establish best effort VCs is considered to be a general IP over ATM failure and is therefore beyond the scope of this document.
实现还必须确保数据流量被发送到尽力而为的接收器。数据流量可以通过best-effort或QoS VCs发送到best-effort接收器，这对于所实现的模型是合适的。在所有情况下，实施不得以无法将数据发送到尽力而为接收器的方式创建VCs。这包括无法向QoS VC添加尽力而为接收器的情况，但不包括无法设置尽力而为VCs的情况。未能建立尽力而为的VCs被视为ATM上的一般IP故障，因此超出了本文件的范围。
There is an interesting interaction between dynamic QoS and heterogeneous requests when using the limited heterogeneity, homogeneous, or modified homogeneous models. 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 signaling is minimized when the setup to the new next-hop fails.
当使用有限的异构、同构或修改的同构模型时，动态QoS和异构请求之间存在有趣的交互。在从新的下一跳接收RESV消息并且请求的资源大于任何现有保留的情况下，需要解决动态QoS和异构性。一个关键问题是，是首先添加新的下一跳，还是更改为新的QoS。这是一个相当直截了当的特例。由于较旧、较小的保留不支持新的下一跳，因此应首先启动动态QoS过程。由于新的QoS只需要新的下一跳，因此它应该是新VC的第一个端点。当新下一跳的设置失败时，这种方式可以最小化信令。
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 usually provide QoS end-points, but not best effort end-points.
实现必须能够识别参与IP多播组的ATM端点。ATM端点将是IP多播接收器和/或下一跳。必须确定QoS和尽力而为的端点。RSVP下一跳信息通常会提供QoS端点，但不会提供尽力而为的端点。
There is a special case where RSVP next-hop information will not provide the appropriate end-points. This occurs when a next-hop is not RSVP capable and RSVP is being automatically tunneled. 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 via a different route than used by the PATH message. The source will get the RESV message, but will not know which ATM end-point should be associated with the reservation. For unicast sessions, there is no problem since the ATM end-point will be the IP next-hop router. There is a problem with
有一种特殊情况，RSVP下一跳信息不会提供适当的端点。当下一个跃点不支持RSVP且RSVP被自动隧道化时，就会发生这种情况。在这种情况下，路径消息在到达下一跳RSVP节点的途中通过非RSVP出口路由器。当下一跳RSVP节点发送RESV消息时，它可能通过与PATH消息使用的不同的路由到达源。源将获得RESV消息，但不知道哪个ATM端点应与保留关联。对于单播会话，没有问题，因为ATM端点将是IP下一跳路由器。这是一个问题
multicast, since multicast routing may not be able to uniquely identify the IP next-hop router. It is therefore possible for a multicast end-point to not be properly identified.
多播，因为多播路由可能无法唯一标识IP下一跳路由器。因此，可能无法正确识别多播端点。
In certain cases it is also possible to identify the list of all best effort end-points. Some multicast over ATM control mechanisms, such as MARS in mesh mode, can be used to identify all end-points of a multicast group. Also, some multicast routing protocols can provide all next-hops for a particular multicast group. In both cases, RSVP over ATM implementations can obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms. The full list can then be compared against the RSVP identified end-points to determine the list of best effort receivers.
在某些情况下，还可以确定所有尽力而为终点的列表。一些ATM上的多播控制机制（如网状模式下的MARS）可用于标识多播组的所有端点。此外，一些多播路由协议可以为特定多播组提供所有下一跳。在这两种情况下，ATM上的RSVP实现都可以使用适当的机制获得完整的端点列表，包括QoS和非QoS。然后可以将完整列表与RSVP确定的端点进行比较，以确定尽力而为的接收者列表。
While there are cases where QoS and best effort end-points can be identified, 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 control mechanisms and routing protocols that support unique end-point identification. In cases where such mechanisms and routing protocols are unavailable, all IP routers that will be used to support RSVP over ATM should support RSVP. To ensure proper behavior, baseline RSVP over ATM implementations MUST only establish RSVP-initiated VCs to RSVP capable end-points. It is permissible to allow a user to override this behavior.
虽然在某些情况下可以识别QoS和尽力而为的端点，但没有简单的解决方案来唯一地识别由非RSVP下一跳处理的多播流量的端点。首选的解决方案是使用支持唯一端点标识的多播控制机制和路由协议。在这种机制和路由协议不可用的情况下，所有用于通过ATM支持RSVP的IP路由器都应支持RSVP。为确保正确的行为，基线RSVP over ATM实施必须仅建立RSVP启动的VCs到RSVP能力端点。允许用户重写此行为是允许的。
Two basic models exist 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. Figure 3 shows data flow for both modes of IP multicast data distribution.
ATM上IP多播数据分发存在两种基本模型。在一种模型中，发送方将点对多点VCs建立到所有ATM连接的目的地，然后通过这些VCs发送数据。这种模型通常被称为“多播网格”或“VC网格”模式分布。在第二种模型中，发送方通过点对点VCs向中心点发送数据，中心点将数据中继到已建立的点对多点VCs上，该VCs已发送到IP多播组的所有接收方。该模型通常被称为“多播服务器”模式分布。图3显示了两种IP多播数据分发模式的数据流。
_________
/ \
/ Multicast \
\ Server /
\_________/
^ | |
| | +--------+
+-----+ | | |
| | -------+ | | Data Flow:
| Src | ...+......|....+ V ----> Server
| | : | : +----+ ....> Mesh
+-----+ : | +...>| R1 |
: | +----+
: V
: +----+
+..> | R2 |
+----+
_________
/ \
/ Multicast \
\ Server /
\_________/
^ | |
| | +--------+
+-----+ | | |
| | -------+ | | Data Flow:
| Src | ...+......|....+ V ----> Server
| | : | : +----+ ....> Mesh
+-----+ : | +...>| R1 |
: | +----+
: V
: +----+
+..> | R2 |
+----+
Figure 3: IP Multicast Data Distribution Over ATM
图3:ATM上的IP多播数据分布
The goal of RSVP over ATM solutions is to ensure that IP multicast data is distributed with appropriate QoS. Current multicast servers [1,2] do not support any mechanisms for communicating QoS requirements to a multicast server. For this reason, RSVP over ATM implementations SHOULD 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). Use of the service-specific break bit tells the receiver(s) that RSVP and Integrated Services are supported by the router but that the service cannot be delivered over the ATM network for the specific request.
RSVP over ATM解决方案的目标是确保IP多播数据以适当的QoS分发。当前的多播服务器[1,2]不支持将QoS要求传达给多播服务器的任何机制。因此，ATM上的RSVP实现应该支持RSVP控制的多播流的“网状模式”分布。当使用不支持QoS请求的多播服务器时，发送方必须设置服务（而不是全局）中断位。使用特定于服务的中断位告诉接收方，路由器支持RSVP和综合服务，但不能通过ATM网络为特定请求提供服务。
In the case of MARS [1], the selection of distribution modes is administratively controlled. Therefore network administrators that desire proper RSVP over ATM operation MUST appropriately configure their network to support mesh mode distribution for multicast groups that will be used in RSVP sessions. For LANE1.0 networks the only multicast distribution option is over the LANE Broadcast and Unknown Server which means that the break bit MUST always be set. For LANE2.0 [3] there are provisions that allow for non-server solutions with which it may be possible to ensure proper QoS delivery.
在MARS[1]的情况下，分配模式的选择受管理控制。因此，希望通过ATM进行适当RSVP操作的网络管理员必须适当配置其网络，以支持RSVP会话中使用的多播组的网状模式分布。对于LANE1.0网络，唯一的多播分发选项是通过车道广播和未知服务器，这意味着必须始终设置中断位。对于LANE2.0[3]，有一些条款允许非服务器解决方案，通过这些解决方案可以确保适当的QoS交付。
When setting up a point-to-multipoint VCs there will be a time when some receivers have been added to a QoS VC and some have not.
在设置点对多点VCs时，有些接收机已添加到QoS VC，而有些尚未添加。
During such transition times it is possible to start sending data on the newly established VC. If data is sent both on the new VC and the old VC, then data will be delivered with proper QoS to some receivers and with the old QoS to all receivers. Additionally, the QoS receivers would get duplicate data. If data is sent just on the new QoS VC, the receivers that have not yet been added will miss data. So, the issue comes down to whether to send to both the old and new VCs, or to just send to one of the VCs. In one case duplicate data will be received, in the other some data may not be received. This issue needs to be considered for three cases: when establishing the first QoS VC, when establishing a VC to support a QoS change, and when adding a new end-point to an already established QoS VC.
在这种转换期间，可以在新建立的VC上开始发送数据。如果数据同时在新VC和旧VC上发送，则数据将以适当的QoS发送给某些接收器，并以旧的QoS发送给所有接收器。此外，QoS接收器将获得重复数据。如果数据仅在新的QoS VC上发送，则尚未添加的接收器将丢失数据。因此，问题归结为是同时发送给新旧风险投资公司，还是只发送给其中一家风险投资公司。在一种情况下，将接收重复数据，而在另一种情况下，可能无法接收某些数据。在三种情况下需要考虑这个问题：在建立第一个QoS VC时，在建立支持QoS更改的VC时，以及在向已经建立的QoS VC添加新端点时。
The first two cases are essentially the same. In both, it is possible to send data on the partially completed new VC. In both, there is the option of duplicate or lost data. In order to ensure predictable behavior and to conform to the requirement to deliver data to all receivers, data MUST NOT be sent on new VCs until all parties have been added. This will ensure that all data is only delivered once to all receivers.
前两种情况基本相同。在这两种情况下，都可以在部分完成的新VC上发送数据。在这两种情况下，都可以选择重复或丢失数据。为了确保可预测的行为，并符合向所有接收者交付数据的要求，在添加所有各方之前，不得在新的VCs上发送数据。这将确保所有数据只向所有接收器发送一次。
The last case differs from the others and occurs 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 data. If the drop is requested first, then the end-point may miss data. In order to avoid loss of data, the add MUST be completed first and then followed by the drop. This behavior requires receivers to be prepared to receive some duplicate packets at times of QoS setup.
最后一种情况与其他情况不同，发生在必须将端点添加到现有QoS VC时。在这种情况下，端点必须既添加到QoS VC中，又从尽力而为的VC中删除。问题是先做什么。如果首先请求添加，则端点可能会获得重复数据。如果首先请求删除，则端点可能会丢失数据。为了避免数据丢失，必须先完成添加，然后再完成删除。这种行为要求接收者准备在QoS设置时接收一些重复的数据包。
The same considerations stated in [8] and [11] apply to this document. There are no additional security issues raised in this document.
[8]和[11]中所述的注意事项同样适用于本文件。本文档中没有提出其他安全问题。
This work is based on earlier drafts and comments from the ISSLL working group. The author would like to acknowledge their contribution, most notably Steve Berson who coauthored one of the drafts.
这项工作基于ISSLL工作组的早期草案和评论。作者要感谢他们的贡献，尤其是史蒂夫·贝尔森，他是其中一份草稿的合著者。
Lou Berger FORE Systems 1595 Spring Hill Road 5th Floor Vienna, VA 22182
弗吉尼亚州维也纳市斯普林山路1595号5楼Lou Berger FORE Systems 22182
Phone: +1 703-245-4527
EMail: lberger@fore.com
Phone: +1 703-245-4527
EMail: lberger@fore.com
REFERENCES
参考资料
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks," RFC 2022, November 1996.
[1] Armitage，G.，“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[2] The ATM Forum, "LAN Emulation Over ATM Specification", Version 1.0.
[2] ATM论坛，“ATM规范上的局域网仿真”，版本1.0。
[3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI Specification", April 1997.
[3] ATM论坛，“ATM版本2上的局域网仿真-LUNI规范”，1997年4月。
[4] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[4] ATM论坛，“MPOA基线版本1”，1997年5月。
[5] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
[5] Berger，L.，“ATM上的RSVP实施指南”，BCP 24，RFC 2379，1998年8月。
[6] Borden, M., and M. Garrett, "Interoperation of Controlled-Load and Guaranteed-Service with ATM", RFC 2381, August 1998.
[6] Borden，M.和M.Garrett，“受控负载和保证服务与ATM的互操作”，RFC 2381，1998年8月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[8] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[9] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998.
[9] Crawley，E.，Berger，L.，Berson，S.，Baker，F.，Borden，M.，和J.Krawczyk，“ATM上的综合服务和RSVP框架”，RFC 2382，1998年8月。
[10] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[10] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[11] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[11] Perez，M.，Liaw，F.，Grossman，D.，Mankin，A.，Hoffman，E.，和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0 Update", RFC 2331, April 1998.
[12] Maher，M.“ATM上IP的ATM信令支持——UNI 4.0更新”，RFC 2331，1998年4月。
Full Copyright Statement
完整版权声明
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。