Network Working Group L. Berger
Request for Comments: 2379 FORE Systems
BCP: 24 August 1998
Category: Best Current Practice
Network Working Group L. Berger
Request for Comments: 2379 FORE Systems
BCP: 24 August 1998
Category: Best Current Practice
RSVP over ATM Implementation Guidelines
ATM上的RSVP实施指南
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). The general problem is discussed in [6]. Implementation requirements are discussed in [2]. Integrated Services to ATM service mappings are covered in [3]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.
本备忘录提供了在ATM交换虚拟电路（SVC）上运行RSVP的具体实施指南。一般问题在[6]中讨论。实现要求在[2]中讨论。[3]中介绍了综合服务到ATM服务的映射。全套文件介绍了在ATM上实施综合业务和RSVP所需的背景和信息。
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 methods for supporting IP over ATM. The general issues related to running RSVP[4] over ATM have been covered in several papers including [6] and other earlier work. This document is intended as a companion to [6,2] and as a guide to implementers. The reader should be familiar with both documents.
本备忘录讨论了在使用SVC支持QoS流且使用RSVP作为internet级QoS信令协议的环境中通过ATM运行IP。它适用于使用CLIP/ION、LANE2.0和MPOA方法来支持ATM上的IP。与在ATM上运行RSVP[4]相关的一般问题已经在几篇论文中讨论过，包括[6]和其他早期工作。本文件旨在作为[6,2]的配套文件，并作为实施者的指南。读者应熟悉这两个文件。
This document provides a recommended set of functionality for implementations using ATM UNI3.x and 4.0, while allowing for more sophisticated approaches. We expect some vendors to additionally provide some of the more sophisticated approaches described in [6], and some networks to only make use of such approaches. The recommended set of functionality is defined to ensure predictability and interoperability between different implementations. Requirements for RSVP over ATM implementations are provided in [2].
本文档为使用ATM UNI3.x和4.0的实现提供了一组推荐的功能，同时允许使用更复杂的方法。我们希望一些供应商另外提供[6]中描述的一些更复杂的方法，一些网络仅使用这些方法。定义推荐的功能集是为了确保不同实现之间的可预测性和互操作性。[2]中提供了通过ATM实现RSVP的要求。
This document uses the same terms and assumption stated in [2]. Additionally, 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 [5].
本文件使用与[2]中所述相同的术语和假设。此外，本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
This section provides implementation guidelines for implementation of RSVP over ATM. Several recommendations are common for all, RSVP sessions, both unicast and multicast. There are also recommendations that are unique to unicast and multicast session types.
本节提供了通过ATM实现RSVP的实施指南。对于所有RSVP会话（单播和多播）都有一些常见的建议。还有一些建议是单播和多播会话类型所独有的。
The general issues related to which VC should be used for RSVP messages is covered in [6]. It discussed several implementation options including: mixed control and data, single control VC per session, single control VC multiplexed among sessions, and multiple VCs multiplexed among sessions. QoS for control VCs was also discussed. The general discussion is not repeated here and [6] should be reviewed for detailed information.
[6]中介绍了与RSVP消息应使用哪个VC相关的一般问题。它讨论了几个实现选项，包括：混合控制和数据、每个会话的单控制VC、会话间多路复用的单控制VC以及会话间多路复用的多个VCs。讨论了控制VCs的QoS问题。此处不再重复一般性讨论，详细信息请参见[6]。
RSVP over ATM implementations SHOULD send RSVP control (messages) over the best effort data path, see figure 1. It is permissible to allow a user to override this behavior. The stated approach minimizes VC requirements since the best effort data path will need to exist in order for RSVP sessions to be established and in order for RSVP reservations to be initiated. The specific best effort paths that will be used by RSVP are: for unicast, the same VC used to reach the unicast destination; and for multicast, the same VC that is used for best effort traffic destined to the IP multicast group. Note that for multicast there may be another best effort VC that is used to carry session data traffic, i.e., for data that is both in the multicast group and matching a sessions protocol and port.
ATM上的RSVP实现应通过尽力而为的数据路径发送RSVP控制（消息），见图1。允许用户重写此行为是允许的。所述方法将VC要求降至最低，因为为了建立RSVP会话和启动RSVP预留，需要存在尽力而为的数据路径。RSVP将使用的特定尽力而为路径是：对于单播，用于到达单播目的地的相同VC；对于多播，与用于发送到IP多播组的尽力而为流量的VC相同。请注意，对于多播，可能存在另一个用于承载会话数据流量的尽力而为VC，即，对于多播组中的数据以及与会话协议和端口匹配的数据。
Data Flow ==========>
Data Flow ==========>
QoS VCs
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
RSVP Control
Messages
QoS VCs
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
RSVP Control
Messages
Figure 1: RSVP Control Message VC Usage
图1:RSVP控制消息VC用法
The disadvantage of this approach is that best effort VCs may not provide the reliability that RSVP needs. However the best effort path is expected to satisfy RSVP reliability requirements in most networks. Especially since RSVP allows for a certain amount of packet loss without any loss of state synchronization.
这种方法的缺点是尽力而为的VCs可能无法提供RSVP所需的可靠性。然而，在大多数网络中，最大努力路径有望满足RSVP可靠性要求。特别是因为RSVP允许一定量的数据包丢失，而不会丢失任何状态同步。
As discussed in [6], data associated with multiple RSVP sessions can be sent using the same shared VCs. Implementation of such "aggregation" models is still a matter for research. Therefore, RSVP over ATM implementations SHOULD use independent VCs for each RSVP reservation.
如[6]所述，与多个RSVP会话相关的数据可以使用相同的共享VCs发送。这种“聚合”模型的实现仍然是一个有待研究的问题。因此，ATM上的RSVP实现应该为每个RSVP预留使用独立的VCs。
Short-cuts 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. Short-cut support for unicast traffic has been defined in [7] and [1]. The ability for short-cuts and RSVP to interoperate has been raised as a general question. The 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, which is shown in figure 2, PATH and RESV messages following different paths.
捷径允许ATM连接的路由器和主机跨LIS边界直接建立点对点VCs，即VC端点位于不同的IP子网上。[7]和[1]中定义了单播流量的快捷支持。捷径和RSVP的互操作能力已作为一个普遍问题提出。关注的领域是处理不对称捷径的能力。具体而言，RSVP如何处理下游捷径可能没有匹配上游捷径的情况。在本例中，如图2所示，PATH和RESV消息遵循不同的路径。
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESVs Follow
| \______/ | Hop-by-hop Path
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESVs Follow
| \______/ | Hop-by-hop Path
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
/\
:: Data Paths:
:: ----> Hop-by-hop (routed)
PATHs and Data ====> Short-cut
Follow Short-cut
Path
/\
:: Data Paths:
:: ----> Hop-by-hop (routed)
PATHs and Data ====> Short-cut
Follow Short-cut
Path
Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
图2：使用ATM捷径的非对称RSVP消息转发
Examination of RSVP shows that the protocol already includes mechanisms that allows support of the asymmetric paths. The mechanism is the same one used to support RESV messages arriving at the wrong router and the wrong interface. RSVP messages are only processed when they arrive at the proper interface. When messages arrive on the wrong interface, they are forwarded by RSVP. The proper interface is indicated in the NHOP object of the message. So, existing RSVP mechanisms will support the asymmetric paths that can occur when using short-cuts.
对RSVP的检查表明，该协议已经包括允许支持非对称路径的机制。该机制与用于支持到达错误路由器和错误接口的RESV消息的机制相同。RSVP消息只有在到达正确的接口时才被处理。当消息到达错误的接口时，它们由RSVP转发。消息的NHOP对象中指示了正确的接口。因此，现有的RSVP机制将支持使用快捷方式时可能出现的不对称路径。
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.
VC建立的捷径模型在与RSVP一起运行时仍然存在一些问题。主要问题是处理已建立的尽力而为的捷径、何时建立捷径以及仅QoS的捷径。这些问题需要通过RSVP实现来解决。
The key issue to be addressed by RSVP over ATM implementations is when to establish a short-cut for a QoS data flow. RSVP over ATM implementations SHOULD simply follow best effort traffic. When a short-cut has been 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
RSVP over ATM实现需要解决的关键问题是何时为QoS数据流建立捷径。ATM上的RSVP实现应该只遵循尽力而为的流量。当为到达目的地或下一跳的尽力而为流量建立了捷径时，在为到达同一目的地或下一跳的QoS流量设置RSVP触发的VCs时，应使用相同的端点。当路径消息通过尽力而为的捷径转发时，这将自然发生。注意，在这个
approach, when best effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established.
在这种方法中，当尽力而为的捷径永远不会建立时，RSVP触发的QoS捷径也永远不会建立。
Heterogeneous sessions can only occur with multicast RSVP sessions. The issues relating to data VC management of heterogeneous sessions are covered in detail in [6] and are not repeated in this document. 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 3.
异构会话只能与多播RSVP会话一起发生。[6]详细介绍了与异构会话的数据VC管理相关的问题，本文档不再重复。总之，当接收器在单个会话中请求不同级别的QoS时，以及当一些接收器不请求任何QoS时，就会出现异构性。两种类型的异质性如图3所示。
+----+
+------> | 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 3: Types of Multicast Receivers
图3：多播接收器的类型
[6] provides four models for dealing with heterogeneity: full heterogeneity, limited heterogeneity, homogeneous, and modified homogeneous models. The key issue to be addressed by an implementation is providing requested QoS downstream. One of, or some combination of, the discussed models [6] may be used to provide the requested QoS. Unfortunately, none of the described models is the right answer for all cases. For some networks, e.g. public WANs, it is likely that the limited heterogeneous model or a hybrid limited-full heterogeneous model will be desired. In other networks, e.g. LANs, it is likely that a the modified homogeneous model will be desired.
[6] 提供四种处理异质性的模型：完全异质性、有限异质性、同质性和修改的同质性模型。实现要解决的关键问题是在下游提供请求的QoS。所讨论的模型[6]中的一个或其某些组合可用于提供所请求的QoS。不幸的是，所描述的模型都不是所有情况下的正确答案。对于某些网络，例如公共WAN，可能需要有限异构模型或混合有限全异构模型。在其他网络中，例如局域网，很可能需要改进的同构模型。
Since there is not one model that satisfies all cases, implementations SHOULD implement one of either the limited heterogeneity model or the modified homogeneous model. Implementations SHOULD support both approaches and provide the ability to select which method is actually used, but are not required to do so.
因为没有一个模型可以满足所有情况，所以实现应该实现有限的异构模型或修改的异构模型中的一个。实现应该支持这两种方法，并提供选择实际使用哪种方法的能力，但不需要这样做。
The same considerations stated in [4] and [8] apply to this document. There are no additional security issues raised in this document.
[4]和[8]中所述的注意事项同样适用于本文件。本文档中没有提出其他安全问题。
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] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[1] ATM论坛，“MPOA基线版本1”，1997年5月。
[2] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[2] Berger，L.“ATM上的RSVP实施要求”，RFC 2380，1998年8月。
[3] Borden, M., and M. Garrett, "Interoperation of Controlled-Load and Guaranteed-Service with ATM", RFC 2381, August 1998.
[3] Borden，M.和M.Garrett，“受控负载和保证服务与ATM的互操作”，RFC 2381，1998年8月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[4] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] 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.
[6] Crawley，E.，Berger，L.，Berson，S.，Baker，F.，Borden，M.，和J.Krawczyk，“ATM上的综合服务和RSVP框架”，RFC 2382，1998年8月。
[7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[7] Luciani，J.，Katz，D.，Piscitello，D.，和B.Cole，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[8] Perez，M.，Liaw，F.，Grossman，D.，Mankin，A.，Hoffman，E.，和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。