[要約] 要約：RFC 2380は、ATM上でのRSVP（Resource Reservation Protocol）の実装要件についてのガイドラインです。 目的：このRFCの目的は、ATMネットワーク上でRSVPを効果的に実装するための要件と手順を提供することです。
Network Working Group L. Berger
Request for Comments: 2380 FORE Systems
Category: Standards Track August 1998
RSVP over ATM Implementation Requirements
RSVP over ATMの実装要件
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.
Copyright（C）The Internet Society（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.
このメモは、RSVP over ATM Switched Virtual Circuit（SVC）を実行するための特定の実装要件を示しています。複数の実装間の相互運用性と、RSVPおよび統合サービス仕様への準拠を保証する要件を示します。別のドキュメント[5]は、今日のATMネットワークで実行するための特定のガイドラインを提供します。一般的な問題は、[9]で説明されています。統合サービスからATMサービスへのマッピングについては、[6]で説明しています。完全なドキュメントセットには、統合サービスとRSVP over ATMを実装するために必要な背景と情報が記載されています。
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
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をインターネットレベルのQoSシグナリングプロトコルとして使用する環境で、IP over ATMを実行する方法について説明します。 IP over ATMをサポートするためにCLIP / ION、LANE2.0およびMPOA [4]メソッドを使用する場合に適用されます。 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実装によって遵守される必要があります。 ATM上のRSVPの実装者をガイドするためのさらなる推奨事項は、[5]で提供されています。
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スタイルは、予約されたリソースが1人の送信者によって使用されるか、複数の送信者によって共有されるかを決定します。それぞれの詳細については、[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スタイルに依存します。共有スタイルの予約の場合、セッションごとに1つのフローがあります。異なるスタイルの予約の場合、送信者ごと（セッションごと）に1つのフローがあります。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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].
[8]で説明されているインターネットシグナリングプロトコルとしてRSVPを想定しています。読者は[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.
RSVPサポートは、IPv4とIPv6の両方で定義されています。このドキュメントのガイドラインは、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.
UNI 3.xおよび4.0で定義されているATMサービスを想定しています。 ATMは、ポイントツーポイントとポイントツーマルチポイントの両方の仮想回路（VC）に、指定されたサービス品質（QoS）を提供します。 ATMは、相手先固定接続（PVC）と交換仮想回線（SVC）の両方を提供します。相手先固定接続（PVC）環境では、PVCは通常、ポイントツーポイントリンクの代替として使用されます。したがって、サポートの問題はポイントツーポイントリンクに似ています。このメモは、SVCがRSVP over ATMをサポートするために使用されることを前提としています。
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 VCを介してRSVPセッションを集約する方法を選択する必要があります。これらのオプションは[9]でカバーされており、特定の実装ガイドラインは[5]で述べられています。異なるオプションに従う実装間の相互運用性を確保するために、RSVP over ATM実装は、RSVP関連データパケットと同じQoS VCでRSVP（制御）メッセージを送信してはなりません（MUST NOT）。 ATM実装上のRSVPは、ベストエフォートデータパスまたは個別の制御VCのいずれかで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に関連するデータパケットは同じVCで送信されないため、あるタイプのトラフィックをサポートするVCが、他のタイプのトラフィックが残っている間に障害が発生する可能性があります。データパケットに関連付けられたVCに障害が発生し、再確立できない場合、RSVPはこれを割り当て障害として扱う必要があります（SHOULD）。 RSVP制御メッセージの転送に使用されるVCが異常に解放され、再確立できない場合、RSVPに関連付けられたQoS VCも解放する必要があります。関連データVCの解放は、関連データフローの転送状態と予約状態の間の同期を維持するために必要です。
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 VCを確立する必要があり、RSVP対応サブネット受信者が着信QoS VCを受け入れることができる必要があることを意味します。これらの制限はRSVPバージョン1処理ルールと整合性があり、送信者は相互運用性の問題なしに、VCマッピングへの異なるフロー、さらには異なるQoS再ネゴシエーション技術を使用できます。サブネット送信者によって開始および制御されるVCを持つすべてのRSVP over ATMアプローチは相互運用します。図1に、このデータフローVC開始のモデルを示します。
Data Flow ==========>
+-----+
| | --------------> +----+
| 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.
RSVP over ATM実装は、RSVPによって開始されたQoSポイントツーポイントVCで逆方向にデータを送信する場合があります。逆方向データパスで送信する場合、送信者はデータが逆方向トラフィックパラメータに準拠していることを確認する必要があります。トラフィックパラメータはVCイニシエータによって設定されるため、着信側で発信されたトラフィックに対してリソースが要求されない可能性が高くなります。ポイントツーマルチポイントVCでは、逆方向データパスを使用できないことに注意してください。
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.
ATM over IPデータをサポートするVCは、通常、非アクティブタイマーに基づいて破棄されます。 IPはコネクションレスであり、したがってVCが不要になったことを知る方法がないため、このメカニズムが使用されます。 RSVPは明示的なメカニズム（メッセージとタイムアウト）を提供して、関連するデータVCが不要になったときを判断するため、従来のVCタイムアウトメカニズムは必要ありません。さらに、通常の操作では、RSVP実装はリソースを割り当て、それらのリソースがRSVPの指示で解放されるまで割り当てられたままになることを期待しています。したがって、RSVP制御フローをサポートするように設定されたデータVCは、RSVPの指示でのみ解放する必要があります。このようなVCは、VCイニシエーターまたはVCレシーバーのいずれかによる非アクティブのためにタイムアウトしてはなりません。これは、VC TeardownのRFC 1755 [11]のセクション3.4で説明されているように、VCのタイムアウトと競合します。 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 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.
ATM実装上のRSVPでは、RSVPの要求で開始されたVCに対して、[11]で説明されている設定可能な非アクティブタイマーを「無限」に設定する必要があります。 VCイニシエーターで非アクティブタイマーの値を設定しても問題は発生しません。これは、適切な値が発信元で内部的に中継されるためです。 VCレシーバーで非アクティブタイマーを設定することはより困難であり、着信VCがRSVPで開始されたことを通知する何らかのメカニズムが必要になります。この複雑さを回避し、[12]に準拠するために、RSVP over ATM実装は、非アクティブタイマーを使用して受信した接続をクリアしてはなりません（MUST）。
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を変更せずにそのままにしておく必要があります。 QoSデータ配信の中断を最小限に抑えるために、古いVCは変更されません。交換用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を引き続き使用する必要があります。新しい予約が古い予約よりも大きい場合、予約リクエストはエラーで応答する必要があります。新しい予約が古い予約より少ない場合、リクエストは変更が成功したかのように扱われなければなりません（MUST）。より大きな割り当てをそのままにしておくことは最適ではありませんが、ユーザーへのサービスの提供を最大化します。 [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].
1つの追加の問題は、予約ごとに一度に1つのQoS変更しか処理できないことです。最初の交換用VCのセットアップ中に（RSVP）要求されたQoSが変更された場合、交換用VCを解放し、VC交換プロセス全体を再開する必要があります（SHOULD）。実装はまた、[9]ごとに一定期間内に処理される変更の数を制限してもよい（MAY）。
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 VCを介して送信されるデータには、複数のカプセル化オプションがあります。すべてのRSVP over ATM実装は、そのようなQoS VCでRFC 1483 [10]に従ってLLCカプセル化をサポートできる必要があります。実装は、ATMシグナリングで定義されているB-LLIネゴシエーション手順を使用して代替カプセル化をネゴシエートしてもよい（MAY）。[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パケットの伝送にのみ使用されている場合、実装はLLCヘッダーのオーバーヘッドの発生を回避するために、VCベースの多重化をネゴシエートする必要があります（SHOULD）。
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.
RSVP over ATMの実行には、マルチキャストセッションに固有のいくつかの側面があります。このセクションでは、マルチキャストのエンドポイント識別、マルチキャストデータの配布、マルチキャストレシーバーの遷移、およびマルチキャストベストエフォートレシーバーの処理を含むさまざまなQoS値（異質性）を要求するネクストホップについて説明します。ベストエフォートレシーバーの処理は厳密にはRSVPの問題ではありませんが、期待されるベストエフォートのインターネットサービスを維持するためには、RSVP over ATMの実装で対処する必要があります。
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.
異種セッションのデータVC管理に関連する問題は、[9]で詳しく説明されています。要約すると、レシーバーが単一のセッション内でさまざまなレベルのQoSを要求した場合、および一部のレシーバーがQoSを要求しなかった場合にも、異質性が発生します。両方のタイプの異質性を図2に示します。
+----+
+------> | 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 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.
[9]は、異質性を処理するための4つのモデルを提供します。完全な異質性、制限された異質性、同種、および修正された同種モデルです。実装がどのモデルまたはモデルの組み合わせを使用するかに関係なく、実装は通常、特定のデータパケットの複数のコピーを特定のネクストホップ（ATMエンドポイント）に送信してはなりません（MUST NOT）。一部の一時的な重複送信は許容されますが、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.
実装では、データトラフィックがベストエフォートの受信者に送信されるようにする必要もあります。データトラフィックは、実装されたモデルに応じて、ベストエフォートまたはQoS VCを介してベストエフォートレシーバーに送信される場合があります。すべての場合において、実装は、データをベストエフォートレシーバーに送信できないような方法でVCを作成してはなりません（MUST NOT）。これには、QoS VCにベストエフォートレシーバーを追加できない場合が含まれますが、ベストエフォートVCをセットアップできない場合は含まれません。ベストエフォートVCの確立の失敗は、一般的なIP over ATMの失敗と見なされるため、このドキュメントの範囲外です。
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 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.
RSVPネクストホップ情報が適切なエンドポイントを提供しない特別なケースがあります。これは、ネクストホップがRSVP対応ではなく、RSVPが自動的にトンネリングされているときに発生します。この場合、PATHメッセージは、ネクストホップRSVPノードに向かう途中で非RSVP出力ルーターを通過します。ネクストホップRSVPノードがRESVメッセージを送信すると、PATHメッセージで使用されているのとは異なるルートを介して送信元に到着する場合があります。ソースはRESVメッセージを受け取りますが、どのATMエンドポイントを予約に関連付ける必要があるかはわかりません。ユニキャストセッションの場合、ATMエンドポイントがIPネクストホップルータになるため、問題はありません。マルチキャストルーティングでは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.
特定のケースでは、すべてのベストエフォートエンドポイントのリストを特定することも可能です。メッシュモードのMARSなど、ATMマルチキャストメカニズムの一部は、マルチキャストグループのすべてのエンドポイントを識別するために使用できます。また、一部のマルチキャストルーティングプロトコルは、特定のマルチキャストグループにすべてのネクストホップを提供できます。どちらの場合も、RSVP over ATM実装は、適切なメカニズムを使用して、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ネクストホップによって処理されるマルチキャストトラフィックのエンドポイントを一意に識別する簡単なソリューションはありません。推奨されるソリューションは、マルチキャスト制御メカニズムと一意のエンドポイント識別をサポートするルーティングプロトコルを使用することです。そのようなメカニズムとルーティングプロトコルが利用できない場合、RSVP over ATMのサポートに使用されるすべてのIPルーターがRSVPをサポートする必要があります。適切な動作を保証するために、ベースラインRSVP over ATM実装は、RSVP対応のエンドポイントに対してRSVPによって開始されたVCのみを確立する必要があります。ユーザーがこの動作をオーバーライドできるようにすることは許容されます。
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マルチキャストデータ配信には、2つの基本モデルがあります。 1つのモデルでは、送信側がすべてのATM接続先にポイントツーマルチポイントVCを確立し、データはこれらのVCを介して送信されます。このモデルは、「マルチキャストメッシュ」または「VCメッシュ」モードの配布と呼ばれることがよくあります。 2番目のモデルでは、送信者はポイントツーポイントVCを介して中央ポイントにデータを送信し、中央ポイントはIPマルチキャストグループのすべての受信者に確立されているポイントツーマルチポイントVCにデータを中継します。このモデルは、「マルチキャストサーバー」モードの配布と呼ばれることがよくあります。図3は、IPマルチキャストデータ配信の両方のモードのデータフローを示しています。
_________
/ \
/ 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要件をマルチキャストサーバーに通信するメカニズムをサポートしていません。このため、RSVP over ATMの実装では、RSVPで制御されるマルチキャストフローの「メッシュモード」配信をサポートする必要があります（SHOULD）。 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]の場合、配布モードの選択は管理上制御されます。したがって、RSVP over ATMの適切な動作を望むネットワーク管理者は、RSVPセッションで使用されるマルチキャストグループのメッシュモード配信をサポートするようにネットワークを適切に構成する必要があります。 LANE1.0ネットワークの場合、唯一のマルチキャスト配布オプションはLANEブロードキャストおよび不明サーバーを介するものです。つまり、ブレークビットを常に設定する必要があります。 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.
ポイントツーマルチポイントVCを設定する場合、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でのみデータが送信された場合、まだ追加されていない受信者はデータを見逃します。したがって、問題は、古いVCと新しいVCの両方に送信するか、どちらか一方のVCに送信するかだけです。重複データが受信される場合と、一部のデータが受信されない場合があります。この問題は、最初のQoS VCを確立するとき、QoSの変更をサポートするVCを確立するとき、およびすでに確立されているQoS VCに新しいエンドポイントを追加するときの3つのケースについて考慮する必要があります。
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.
最初の2つのケースは基本的に同じです。どちらの場合も、部分的に完成した新しいVCでデータを送信できます。どちらの場合も、データを複製するか、失われる可能性があります。予測可能な動作を保証し、すべての受信者にデータを配信するという要件に準拠するために、すべての関係者が追加されるまで、データを新しいVCで送信してはなりません。これにより、すべてのデータがすべての受信者に1回だけ配信されます。
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ワーキンググループからの以前のドラフトとコメントに基づいています。著者、特にドラフトの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] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks," RFC 2022, November 1996.
[1] アーミテージ、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フォーラム、「LAN Emulation Over ATM Specification」、バージョン1.0。
[3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI Specification", April 1997.
[3] ATMフォーラム、「LANエミュレーションover 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。、「RSVP over ATM実装ガイドライン」、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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年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、「A Framework for Integrated Services and RSVP over ATM」、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 Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0 Update", RFC 2331, April 1998.
[12] Maher、M。、「IP over ATMのATMシグナリングサポート-UNI 4.0アップデート」、RFC 2331、1998年4月。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。