[要約] RFC 2379は、ATM上でのRSVP（Resource Reservation Protocol）の実装ガイドラインを提供しています。このRFCの目的は、ATMネットワークでのRSVPの効果的な利用を促進し、トラフィックエンジニアリングやQoS（Quality of Service）の向上を支援することです。
Network Working Group L. Berger
Request for Comments: 2379 FORE Systems
BCP: 24 August 1998
Category: Best Current Practice
RSVP over ATM Implementation Guidelines
RSVP over ATM実装ガイドライン
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.
Copyright（C）The Internet Society（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.
このメモは、RSVP over ATM Switched Virtual Circuit（SVC）を実行するための具体的な実装ガイドラインを示しています。一般的な問題は、[6]で説明されています。実装要件については、[2]で説明しています。統合サービスからATMサービスへのマッピングについては、[3]で説明しています。完全なドキュメントセットには、統合サービスとRSVP over ATMを実装するために必要な背景と情報が記載されています。
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をインターネットレベルのQoSシグナリングプロトコルとして使用する環境で、IP over ATMを実行する方法について説明します。 IP over ATMをサポートするためにCLIP / ION、LANE2.0、およびMPOA方式を使用する場合に適用されます。 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]で説明されているより高度なアプローチのいくつかを追加で提供することを期待し、一部のネットワークはそのようなアプローチのみを利用することを期待しています。推奨される機能セットは、異なる実装間の予測可能性と相互運用性を確保するために定義されています。 RSVP over ATM実装の要件は、[2]で提供されています。
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]で述べられているのと同じ用語と仮定を使用します。さらに、このキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」ドキュメントは、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.
このセクションでは、RSVP over ATMを実装するための実装ガイドラインを示します。いくつかの推奨事項は、ユニキャストとマルチキャストの両方のすべての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.
RSVPメッセージにどのVCを使用する必要があるかに関する一般的な問題は、[6]で説明されています。制御とデータの混合、セッションごとの単一制御VC、セッション間で多重化された単一制御VC、セッション間で多重化された複数のVCなど、いくつかの実装オプションについて説明しました。制御VCの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.
RSVP over ATM実装は、ベストエフォートデータパスを介してRSVP制御（メッセージ）を送信する必要があります。図1を参照してください。ユーザーがこの動作をオーバーライドできるようにすることは許可されています。 RSVPセッションが確立され、RSVP予約が開始されるためには、ベストエフォートデータパスが存在する必要があるため、上記のアプローチはVC要件を最小限に抑えます。 RSVPが使用する特定のベストエフォートパスは次のとおりです。ユニキャストの場合、ユニキャストの宛先に到達するために使用されるのと同じVC。マルチキャストの場合は、IPマルチキャストグループ宛のベストエフォートトラフィックに使用されるのと同じVC。マルチキャストの場合、セッションデータトラフィックを伝送するために使用される別のベストエフォートVCが存在する可能性があることに注意してください。つまり、マルチキャストグループにあり、セッションのプロトコルとポートに一致するデータの両方です。
Data Flow ==========>
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.
このアプローチの欠点は、ベストエフォートVCが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セッションに関連付けられたデータは、同じ共有VCを使用して送信できます。そのような「集約」モデルの実装は、まだ研究の問題です。したがって、RSVP over ATM実装は、RSVP予約ごとに独立したVCを使用する必要があります（SHOULD）。
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境界を越えてポイントツーポイントVCを直接確立できます。つまり、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) | |
+-----+ <=================> +----+
/\
:: 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.
RSVPで実行する場合、VC確立のショートカットモデルはまだいくつかの問題を引き起こします。主要な問題は、ショートカットを確立するタイミングと、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 approach, when best effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established.
ATM実装上のRSVPで対処する重要な問題は、QoSデータフローのショートカットをいつ確立するかです。 ATM実装上のRSVPは、ベストエフォートトラフィックに従うだけです。宛先またはネクストホップへのベストエフォートトラフィックのショートカットが確立されている場合、同じ宛先またはネクストホップへのQoSトラフィック用にRSVPトリガーVCを設定するときに、その同じエンドポイントを使用する必要があります。これは、PATHメッセージがベストエフォートのショートカットで転送されるときに自然に発生します。このアプローチでは、ベストエフォートのショートカットが確立されない場合、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セッションでのみ発生します。異種セッションのデータVC管理に関連する問題は、[6]で詳細に説明されており、このドキュメントでは繰り返されません。要約すると、単一セッション内でレシーバーがさまざまなレベルのQoSを要求した場合、および一部のレシーバーがQoSを要求しなかった場合にも、異質性が発生します。両方のタイプの異質性を図3に示します。
+----+
+------> | 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] は、異質性を処理するための4つのモデルを提供します。完全な異質性、制限された異質性、同種、および修正された同種モデルです。実装によって対処される重要な問題は、要求されたQoSをダウンストリームで提供することです。説明されているモデル[6]の1つまたはいくつかの組み合わせを使用して、要求されたQoSを提供できます。残念ながら、説明されているモデルはどれも、すべての場合に正しい答えではありません。一部のネットワークでは、パブリックWANでは、限定された異種モデルまたはハイブリッド限定完全異種モデルが望まれる可能性があります。他のネットワークでは、 LANでは、修正された同種モデルが必要になる可能性があります。
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.
すべてのケースを満たすモデルは1つではないため、実装では、制限された不均一性モデルまたは変更された同種モデルのいずれかを実装する必要があります（SHOULD）。実装は両方のアプローチをサポートし、実際に使用する方法を選択する機能を提供する必要がありますが、そうする必要はありません。
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ワーキンググループからの以前のドラフトとコメントに基づいています。著者、特にドラフトの1つを共同執筆したSteve Bersonの貢献に感謝します。
Lou Berger FORE Systems 1595 Spring Hill Road 5th Floor Vienna, VA 22182
Lou Berger FORE Systems 1595 Spring Hill Road 5th Floor Vienna、VA 22182
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。、「RSVP over ATMの実装要件」、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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年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、「A Framework for Integrated Services and RSVP over ATM」、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 Next Hop Resolution Protocol（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 Signaling Support for IP over ATM」、RFC 1755、1995年2月。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。