[要約] RFC 2382は、ATM上での統合サービスとRSVPのためのフレームワークを提供しています。このRFCの目的は、ATMネットワークでの統合サービスの実装と管理を支援することです。
Network Working Group E. Crawley, Editor
Request for Comments: 2382 Argon Networks
Category: Informational L. Berger
Fore Systems
S. Berson
ISI
F. Baker
Cisco Systems
M. Borden
Bay Networks
J. Krawczyk
ArrowPoint Communications
August 1998
A Framework for Integrated Services and RSVP over ATM
統合サービスとRSVP over ATMのフレームワーク
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.
このドキュメントでは、RSVP over ATMによるIP統合サービスの提供に関連する問題とフレームワークの概要を説明します。問題と関連する問題への全体的なアプローチを提供します。これらの問題と問題は、ISSLLワーキンググループのISATMサブグループからのさらなるドキュメントで対処されます。
The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first-serve scheduling at each hop in the network. Best effort service has worked well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded portions of the network. In order to provide quality real-time traffic, new classes of service and a QoS signalling protocol are being introduced in the Internet [1,6,7], while retaining the existing best effort service. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol and the service models
インターネットには現在、通常「ベストエフォート」と呼ばれる1つのサービスクラスがあります。このサービスは、ネットワークの各ホップでの先着順のスケジューリングに代表されます。ベストエフォートサービスは、電子メール、World Wide Web（WWW）アクセス、ファイル転送（ftpなど）などでうまく機能しています。音声やビデオなどのリアルタイムトラフィックの場合、現在のインターネットは、通信網。高品質のリアルタイムトラフィックを提供するために、既存のベストエフォートサービスを維持しながら、新しいサービスクラスとQoSシグナリングプロトコルがインターネットに導入されています[1,6,7]。 QoSシグナリングプロトコルは、RSVP [1]、Resource ReSerVation Protocol、およびサービスモデルです。
One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be added and removed from the VC dynamically and so provides a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer including ATM, and this memo concentrates on ATM.
ATMテクノロジーの重要な機能の1つは、指定されたサービス品質（QoS）でポイントツーポイント仮想回線（VC）を要求する機能です。 ATMテクノロジーの追加機能は、QoSを指定してポイントツーマルチポイントVCを要求する機能です。ポイントツーマルチポイントVCでは、リーフノードをVCに動的に追加したり、VCから削除したりできるため、IPマルチキャストをサポートするメカニズムが提供されます。 RSVPおよびインターネット統合サービス（IIS）モデルが、ATMを含むすべての基礎となるリンク層のQoSプロパティを利用することは当然のことであり、このメモはATMに集中しています。
Classical IP over ATM [10] has solved part of this problem, supporting IP unicast best effort traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within an LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is being solved with MARS [5], the Multicast Address Resolution Server.
従来のIP over ATM [10]はこの問題の一部を解決し、ATM上のIPユニキャストベストエフォートトラフィックをサポートしています。従来のIP over ATMは、個別に管理されるIPサブネットワークである論理IPサブネットワーク（LIS）に基づいています。 LIS内のホストは、ATMネットワークを使用して通信しますが、異なるサブネットのホストは、IPルーターを経由することによってのみ通信します（ATMネットワーク上の2つのホスト間で直接VCを開くことができる場合でも）。従来のIP over ATMは、ATMエッジデバイスがIPアドレスをネイティブATMアドレスに解決するためのアドレス解決プロトコル（ATMARP）を提供します。 IP / ATMエッジデバイスの任意のペア（つまり、ホストまたはルーター）では、単一のVCがオンデマンドで作成され、2つのデバイス間のすべてのトラフィックで共有されます。 RSVPおよびIIS over ATMの問題の2番目の部分であるIPマルチキャストは、マルチキャストアドレス解決サーバーであるMARS [5]で解決されています。
MARS compliments ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address.
MARSは、IPアドレスを単一のアドレスではなく、ネイティブATMアドレスのリストに解決できるようにすることで、ATMARPを補完します。
The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also address the support of IP best effort traffic over ATM through similar means.
ATMフォーラムのLANエミュレーション（LANE）[17、20]とMultiprotocol Over ATM（MPOA）[18]も、同様の方法で、ATM上のIPベストエフォートトラフィックのサポートに対応しています。
A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs.
ATM環境におけるIPの残りの重要な問題は、インターネット統合サービス（IIS）モデルをサポートするRSVPシグナリングとATMシグナリングの統合です。 IISモデルのサポートには、QoS変換とVC管理の2つの主要な領域があります。 QoS変換は、IISモデルから適切なATM QoSへのQoSのマッピングに関係しますが、VC管理は、必要なVCの数と、どのVCを介してルーティングされるトラフィックフローに集中します。
This document provides a guide to the issues for IIS over ATM. It is intended to frame the problems that are to be addressed in further documents. In this document, the modes and models for RSVP operation over ATM will be discussed followed by a discussion of management of ATM VCs for RSVP data and control. Lastly, the topic of encapsulations will be discussed in relation to the models presented.
このドキュメントでは、ATMを介したIISの問題に関するガイドを提供します。これは、今後のドキュメントで対処する必要のある問題をまとめることを目的としています。このドキュメントでは、ATMでのRSVP動作のモードとモデルについて説明した後、RSVPデータと制御のためのATM VCの管理について説明します。最後に、カプセル化のトピックは、提示されたモデルに関連して説明されます。
This document is part of a group of documents from the ISATM subgroup of the ISSLL working group related to the operation of IntServ and RSVP over ATM. [14] discusses the mapping of the IntServ models for Controlled Load and Guaranteed Service to ATM. [15 and 16] discuss detailed implementation requirements and guidelines for RSVP over ATM, respectively. While these documents may not address all the issues raised in this document, they should provide enough information for development of solutions for IntServ and RSVP over ATM.
このドキュメントは、IntServおよびRSVP over ATMの運用に関連するISSLLワーキンググループのISATMサブグループからのドキュメントグループの一部です。 [14]は、ATMへの制御された負荷と保証サービスのIntServモデルのマッピングについて説明しています。 [15と16]は、RSVP over ATMの詳細な実装要件とガイドラインをそれぞれ説明しています。これらのドキュメントは、このドキュメントで提起されたすべての問題を扱っているわけではありませんが、IntServおよびRSVP over ATMのソリューションの開発に十分な情報を提供する必要があります。
Several term used in this document are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
このドキュメントで使用されているいくつかの用語は、多くの場合、さまざまな意味で使用されています。これらの用語は、このドキュメントでは次の意味で使用されています。
- Sender is used in this document to mean the ingress point to the ATM network or "cloud". - Receiver is used in this document to refer to the egress point from the ATM network or "cloud". - Reservation is used in this document to refer to an RSVP initiated request for resources. RSVP initiates requests for resources based on RESV message processing. RESV messages that simply refresh state do not trigger resource requests. Resource requests may be made based on RSVP sessions and RSVP reservation styles. RSVP styles dictate whether the reserved resources are used by one sender or shared by multiple senders. See [1] for details of each. Each new request is referred to in this document as an RSVP reservation, or simply reservation. - Flow is used to refer to the data traffic associated with a particular reservation. The specific meaning of flow is RSVP style dependent. For shared style reservations, there is one flow per session. For distinct style reservations, there is one flow per sender (per session).
- このドキュメントでは、送信者は、ATMネットワークまたは「クラウド」への入口ポイントを意味するために使用されています。 -このドキュメントでは、レシーバーを使用して、ATMネットワークまたは「クラウド」からの出力ポイントを指します。 -このドキュメントでは、RSVPによって開始されたリソースの要求を指すために予約が使用されています。 RSVPは、RESVメッセージ処理に基づいてリソースの要求を開始します。単に状態を更新するRESVメッセージは、リソース要求をトリガーしません。リソース要求は、RSVPセッションおよびRSVP予約スタイルに基づいて行われる場合があります。 RSVPスタイルは、予約されたリソースが1人の送信者によって使用されるか、複数の送信者によって共有されるかを決定します。それぞれの詳細については、[1]を参照してください。このドキュメントでは、新しい各要求をRSVP予約、または単に予約と呼びます。 -フローは、特定の予約に関連付けられたデータトラフィックを参照するために使用されます。フローの具体的な意味は、RSVPスタイルに依存します。共有スタイルの予約の場合、セッションごとに1つのフローがあります。異なるスタイルの予約の場合、送信者ごと（セッションごと）に1つのフローがあります。
The issues related to RSVP and IntServ over ATM fall into several general classes:
RSVPおよびATM上のIntServに関連する問題は、いくつかの一般的なクラスに分類されます。
- How to make RSVP run over ATM now and in the future - When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP - How to map the IntServ models to ATM QoS models - How to know that an ATM network is providing the QoS necessary for a flow - How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to-many connection-oriented world of ATM
- RSVPを現在および将来的にATM上で実行する方法-RSVPに関連する特定のサービス品質（QoS）の仮想回線（VC）をセットアップする場合-IntServモデルをATM QoSモデルにマップする方法-知る方法ATMネットワークがフローに必要なQoSを提供していること-ATMの1対多のコネクション型の世界でIPマルチキャストとRSVPの多対多のコネクションレス機能を処理する方法
[3] Discusses several different models for running IP over ATM networks. [17, 18, and 20] also provide models for IP in ATM environments. Any one of these models would work as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. It is important that the RSVP PATH messages follow the same IP path as the data such that appropriate PATH state may be installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points must be the same in both directions for the RSVP control and data messages. Note that the RSVP protocol does not require symmetric routing. The PATH state installed by RSVP allows the RESV messages to "retrace" the hops that the PATH message crossed. Within each of the models for IP over ATM, there are decisions about using different types of data distribution in ATM as well as different connection initiation. The following sections look at some of the different ways QoS connections can be set up for RSVP.
[3] ATM over IPネットワークを実行するためのいくつかの異なるモデルについて説明します。 [17、18、および20]は、ATM環境でのIPのモデルも提供します。 RSVP制御パケット（IPプロトコル46）とデータパケットがネットワークを介して同じIPパスをたどることができる限り、これらのモデルのいずれかが機能します。 RSVP PATHメッセージがデータと同じIPパスをたどり、パスに沿ってルーターに適切なPATH状態がインストールされるようにすることが重要です。 ATMサブネットワークの場合、これは、RSVP制御およびデータメッセージの入力ポイントと出力ポイントが両方向で同じでなければならないことを意味します。 RSVPプロトコルは対称ルーティングを必要としないことに注意してください。 RSVPによってインストールされたPATH状態により、RESVメッセージは、PATHメッセージが通過したホップを「リトレース」できます。 IP over ATMの各モデル内では、ATMでのさまざまなタイプのデータ配信の使用と、さまざまな接続開始についての決定があります。次のセクションでは、RSVP用にQoS接続を設定するさまざまな方法をいくつか紹介します。
In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9] and 4.0 specification, both permanent and switched virtual circuits (PVC and SVC) may be established with a specified service category (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and specific traffic descriptors in point-to-point and point-to-multipoint configurations. Additional QoS parameters are not available in UNI 3.x and those that are available are vendor-specific. Consequently, the level of QoS control available in standard UNI 3.x networks is somewhat limited. However, using these building blocks, it is possible to use RSVP and the IntServ models. ATM 4.0 with the Traffic Management (TM) 4.0 specification [21] allows much greater control of QoS. [14] provides the details of mapping the IntServ models to UNI 3.x and 4.0 service categories and traffic parameters.
User Network Interface（UNI）3.0および3.1仕様[8、9]および4.0仕様では、指定されたサービスカテゴリ（CBR、VBR、およびUNI 3のUBR）を使用して、パーマネント仮想回線と交換仮想回線（PVCおよびSVC）の両方を確立できます。 .xおよびVBR-rtおよび4.0 for ABR）、およびポイントツーポイントおよびポイントツーマルチポイント構成の特定のトラフィック記述子。追加のQoSパラメータはUNI 3.xでは使用できません。使用可能なパラメータはベンダー固有です。その結果、標準のUNI 3.xネットワークで使用できるQoS制御のレベルは多少制限されます。ただし、これらのビルディングブロックを使用すると、RSVPおよびIntServモデルを使用できます。トラフィック管理（TM）4.0仕様[21]を備えたATM 4.0は、QoSのはるかに優れた制御を可能にします。 [14]は、IntServモデルをUNI 3.xおよび4.0サービスカテゴリとトラフィックパラメータにマッピングする詳細を提供します。
PVCs emulate dedicated point-to-point lines in a network, so the operation of RSVP can be identical to the operation over any point-to-point network. The QoS of the PVC must be consistent and equivalent to the type of traffic and service model used. The devices on either end of the PVC have to provide traffic control services in order to multiplex multiple flows over the same PVC. With PVCs, there is no issue of when or how long it takes to set up VCs, since they are made in advance but the resources of the PVC are limited to what has been pre-allocated. PVCs that are not fully utilized can tie up ATM network resources that could be used for SVCs.
PVCはネットワーク内の専用のポイントツーポイント回線をエミュレートするため、RSVPの操作は、任意のポイントツーポイントネットワークでの操作と同じにすることができます。 PVCのQoSは一貫しており、使用するトラフィックのタイプとサービスモデルと同等である必要があります。同じPVC上で複数のフローを多重化するには、PVCの両端のデバイスがトラフィック制御サービスを提供する必要があります。 PVCを使用すると、事前に作成されるため、VCのセットアップにいつどのくらいの時間がかかるかという問題はありませんが、PVCのリソースは事前に割り当てられたリソースに制限されます。十分に活用されていないPVCは、SVCに使用できるATMネットワークリソースを占有する可能性があります。
An additional issue for using PVCs is one of network engineering. Frequently, multiple PVCs are set up such that if all the PVCs were running at full capacity, the link would be over-subscribed. This frequently used "statistical multiplexing gain" makes providing IIS over PVCs very difficult and unreliable. Any application of IIS over PVCs has to be assured that the PVCs are able to receive all the requested QoS.
PVCの使用に関する追加の問題は、ネットワークエンジニアリングの1つです。多くの場合、複数のPVCがセットアップされ、すべてのPVCがフルキャパシティで実行されている場合、リンクはオーバーサブスクライブされます。この頻繁に使用される「統計的多重化ゲイン」により、PVCを介したIISの提供が非常に困難で信頼性が低くなります。 PVCを介したIISのすべてのアプリケーションは、PVCが要求されたすべてのQoSを受信できることを保証する必要があります。
SVCs allow paths in the ATM network to be set up "on demand". This allows flexibility in the use of RSVP over ATM along with some complexity. Parallel VCs can be set up to allow best-effort and better service class paths through the network, as shown in Figure 1. The cost and time to set up SVCs can impact their use. For example, it may be better to initially route QoS traffic over existing VCs until a SVC with the desired QoS can be set up for the flow. Scaling issues can come into play if a single RSVP flow is used per VC, as will be discussed in Section 4.3.1.1. The number of VCs in any ATM device may also be limited so the number of RSVP flows that can be supported by a device can be strictly limited to the number of VCs available, if we assume one flow per VC. Section 4 discusses the topic of VC management for RSVP in greater detail.
SVCを使用すると、ATMネットワーク内のパスを「オンデマンド」で設定できます。これにより、RSVP over ATMを柔軟に使用できるようになり、複雑さも増します。並列VCは、図1に示すように、ネットワークを介してベストエフォートでより良いサービスクラスパスを許可するように設定できます。SVCを設定するコストと時間は、その使用に影響を与える可能性があります。たとえば、フローに必要なQoSを備えたSVCを設定できるようになるまで、最初に既存のVCを介してQoSトラフィックをルーティングする方が適切な場合があります。 4.3.1.1項で説明するように、VCごとに単一のRSVPフローが使用される場合、スケーリングの問題が発生する可能性があります。 ATMデバイスのVCの数も制限される可能性があるため、VCごとに1つのフローを想定すると、デバイスでサポートできるRSVPフローの数を、使用可能なVCの数に厳密に制限できます。セクション4では、RSVPのVC管理のトピックについて詳しく説明します。
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
Figure 1: Data Flow VC Initiation
図1：データフローVCの開始
While RSVP is receiver oriented, ATM is sender oriented. This might seem like a problem but the sender or ingress point receives RSVP RESV messages and can determine whether a new VC has to be set up to the destination or egress point.
RSVPは受信者指向ですが、ATMは送信者指向です。これは問題のように思えるかもしれませんが、送信側または入力ポイントはRSVP RESVメッセージを受信し、宛先または出力ポイントに新しいVCを設定する必要があるかどうかを判断できます。
In order to provide QoS for IP multicast, an important feature of RSVP, data flows must be distributed to multiple destinations from a given source. Point-to-multipoint VCs provide such a mechanism. It is important to map the actions of IP multicasting and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x and UNI 4.0 have a single service class for all destinations. This is contrary to the RSVP "heterogeneous receiver" concept. It is possible to set up a different VC to each receiver requesting a different QoS, as shown in Figure 2. This again can run into scaling and resource problems when managing multiple VCs on the same interface to different destinations.
RSVPの重要な機能であるIPマルチキャストにQoSを提供するには、データフローを特定の送信元から複数の宛先に分散する必要があります。ポイントツーマルチポイントVCは、このようなメカニズムを提供します。 ATMのパーティー機能とドロップパーティー機能を追加するには、IPマルチキャストとRSVP（IGMP JOIN / LEAVEおよびRSVP RESV / RESV TEARなど）のアクションをマップすることが重要です。 UNI 3.xおよびUNI 4.0で定義されているポイントツーマルチポイントVCには、すべての宛先に対して単一のサービスクラスがあります。これは、RSVPの「ヘテロジニアスレシーバー」の概念に反しています。図2に示すように、異なるQoSを要求する各レシーバーに異なるVCを設定することが可能です。これは、異なる宛先への同じインターフェイスで複数のVCを管理するときに、スケーリングとリソースの問題に遭遇する可能性があります。
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Multicast
Group
Figure 2: Types of Multicast Receivers
図2：マルチキャストレシーバーのタイプ
RSVP sends messages both up and down the multicast distribution tree. In the case of a large ATM cloud, this could result in a RSVP message implosion at an ATM ingress point with many receivers.
RSVPは、マルチキャスト配信ツリーの上下にメッセージを送信します。大規模なATMクラウドの場合、これにより、多くのレシーバーがあるATM入力ポイントでRSVPメッセージが爆破する可能性があります。
ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf Initiated Join (LIJ) capability. LIJ allows an ATM end point to join into an existing point-to-multipoint VC without necessarily contacting the source of the VC. This can reduce the burden on the ATM source point for setting up new branches and more closely matches the receiver-based model of RSVP and IP multicast. However, many of the same scaling issues exist and the new branches added to a point-to-multipoint VC must use the same QoS as existing branches.
ATM 4.0は、Leaf Initiated Join（LIJ）機能を追加することにより、ポイントツーマルチポイントVCを拡張します。 LIJを使用すると、ATMエンドポイントは、VCの送信元に必ずしも接続することなく、既存のポイントツーマルチポイントVCに参加できます。これにより、新しいブランチをセットアップするためのATMソースポイントの負担が軽減され、RSVPおよびIPマルチキャストの受信者ベースのモデルにより厳密に一致します。ただし、同じスケーリング問題の多くが存在し、ポイントツーマルチポイントVCに追加される新しいブランチは、既存のブランチと同じQoSを使用する必要があります。
IP-over-ATM has the concept of a multicast server or reflector that can accept cells from multiple senders and send them via a point-to-multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server. Additionally, the multicast server will need to know how to interpret RSVP packets or receive instruction from another node so it will be able to provide VCs of the appropriate QoS for the RSVP flows.
IP-over-ATMには、複数の送信者からのセルを受け入れ、それらをポイントツーマルチポイントVC経由で受信者のセットに送信できるマルチキャストサーバーまたはリフレクターの概念があります。これにより、ポイントツーマルチポイントVCについて前述したVCスケーリングの問題がマルチキャストサーバーに移動します。さらに、マルチキャストサーバーは、RSVPパケットを解釈する方法、または別のノードからの指示を受信する方法を知っている必要があるため、RSVPフローに適切なQoSのVCを提供できます。
If the ATM "cloud" is made up a number of logical IP subnets (LISs), then it is possible to use "short cuts" from a node on one LIS directly to a node on another LIS, avoiding router hops between the LISs. NHRP [4], is one mechanism for determining the ATM address of the egress point on the ATM network given a destination IP address. It is a topic for further study to determine if significant benefit is achieved from short cut routes vs. the extra state required.
ATM「クラウド」がいくつかの論理IPサブネット（LIS）で構成されている場合、LIS間のルーターホップを回避して、あるLISのノードから別のLISのノードに直接「ショートカット」を使用することが可能です。 NHRP [4]は、宛先IPアドレスを指定して、ATMネットワーク上の出力ポイントのATMアドレスを決定するための1つのメカニズムです。必要な追加の状態と比較して、ショートカットルートから大きな利益が得られるかどうかを判断することは、今後の研究のトピックです。
ATM is constantly evolving. If we assume that RSVP and IntServ applications are going to be wide-spread, it makes sense to consider changes to ATM that would improve the operation of RSVP and IntServ over ATM. Similarly, the RSVP protocol and IntServ models will continue to evolve and changes that affect them should also be considered. The following are a few ideas that have been discussed that would make the integration of the IntServ models and RSVP easier or more complete. They are presented here to encourage continued development and discussion of ideas that can help aid in the integration of RSVP, IntServ, and ATM.
ATMは常に進化しています。 RSVPおよびIntServアプリケーションが広く普及すると想定する場合、ATMに対するRSVPおよびIntServの動作を改善するATMへの変更を検討することは理にかなっています。同様に、RSVPプロトコルとIntServモデルは進化し続け、それらに影響する変更も考慮する必要があります。以下は、IntServモデルとRSVPの統合をより簡単またはより完全にする、議論されたいくつかのアイデアです。これらは、RSVP、IntServ、およびATMの統合に役立つ可能性があるアイデアの継続的な開発と議論を促進するためにここに提示されています。
The IntServ models and RSVP support the idea of "heterogeneous receivers"; e.g., not all receivers of a particular multicast flow are required to ask for the same QoS from the network, as shown in Figure 2.
IntServモデルとRSVPは、「異種レシーバー」の概念をサポートしています。たとえば、図2に示すように、特定のマルチキャストフローのすべての受信者がネットワークから同じQoSを要求する必要はありません。
The most important scenario that can utilize this feature occurs when some receivers in an RSVP session ask for a specific QoS while others receive the flow with a best-effort service. In some cases where there are multiple senders on a shared-reservation flow (e.g., an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. However, other receivers may elect to reserve more resources, perhaps to allow for some amount of "over-speaking" or in order to record the conference (post processing during playback can separate the senders by their source addresses).
この機能を利用できる最も重要なシナリオは、RSVPセッションの一部の受信者が特定のQoSを要求する一方で、他の受信者がベストエフォートサービスでフローを受信する場合に発生します。共有予約フロー（オーディオ会議など）に複数の送信者がいる場合、個々の受信者は一度に1人の送信者を受信するのに十分なリソースを予約するだけで済みます。ただし、他の受信者はより多くのリソースを予約することを選択する場合があります。これは、ある程度の「オーバースピーキング」を可能にするため、または会議を記録するためです（再生中の後処理で送信元を送信元アドレスで分離できます）。
In order to prevent denial-of-service attacks via reservations, the service models do not allow the service elements to simply drop non-conforming packets. For example, Controlled Load service model [7] assigns non-conformant packets to best-effort status (which may result in packet drops if there is congestion).
予約によるサービス拒否攻撃を防ぐために、サービスモデルでは、サービス要素が単に非準拠パケットをドロップすることを許可していません。たとえば、Controlled Loadサービスモデル[7]は、非適合パケットをベストエフォートステータスに割り当てます（輻輳があると、パケットがドロップされる可能性があります）。
Emulating these behaviors over an ATM network is problematic and needs to be studied. If a single maximum QoS is used over a point-to-multipoint VC, resources could be wasted if cells are sent over certain links where the reassembled packets will eventually be dropped. In addition, the "maximum QoS" may actually cause a degradation in service to the best-effort branches.
ATMネットワークでこれらの動作をエミュレートすることは問題があり、調査する必要があります。ポイントツーマルチポイントVCで単一の最大QoSが使用されている場合、再構成されたパケットが最終的にドロップされる特定のリンクでセルが送信されると、リソースが浪費される可能性があります。さらに、「最大QoS」は実際には、ベストエフォートブランチへのサービスの低下を引き起こす可能性があります。
The term "variegated VC" has been coined to describe a point-to-multipoint VC that allows a different QoS on each branch. This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to be put into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one. The "best-effort for non-conforming packets" behavior must also be retained. Early Packet Discard (EPD) schemes must be used so that all the cells for a given packet can be discarded at the same time rather than discarding only a few cells from several packets making all the packets useless to the receivers.
「多彩なVC」という用語は、各ブランチで異なるQoSを可能にするポイントツーマルチポイントVCを表すために作られたものです。このアプローチは統合サービスおよびRSVPモデルの精神と一致するようですが、「より大きな」ブランチから「より小さな」ブランチに移動するときに、セルドロップ戦略にいくつかの考慮が必要です。 「非準拠パケットのベストエフォート」動作も維持する必要があります。いくつかのパケットから少数のセルだけを破棄してすべてのパケットを受信者にとって役に立たなくするのではなく、特定のパケットのすべてのセルを同時に破棄できるように、早期パケット破棄（EPD）スキームを使用する必要があります。
Q.2931 signalling is very complete and carries with it a significant burden for signalling in all possible public and private connections. It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks.
Q.2931シグナリングは非常に完全であり、すべての可能なパブリックおよびプライベート接続でのシグナリングに対する大きな負担を伴います。プライベートネットワークでの接続セットアップを高速化するために、軽量のシグナリングメカニズムを調査する価値があるかもしれません。
Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC. This would eliminate the need to setup and tear down VCs as the QoS changed. RSVP allows receivers to change their reservations and senders to change their traffic descriptors dynamically. This, along with the merging of reservations, can create a situation where the QoS needs of a VC can change. Allowing changes to the QoS of an existing VC would allow these features to work without creating a new VC. In the ITU-T ATM specifications [24,25], some cell rates can be renegotiated or changed. Specifically, the Peak Cell Rate (PCR) of an existing VC can be changed and, in some cases, QoS parameters may be renegotiated during the call setup phase. It is unclear if this is sufficient for the QoS renegotiation needs of the IntServ models.
ATM上のRSVPを支援するもう1つの変更は、アクティブなVCに対して異なるQoSを要求する機能です。これにより、QoSが変更されたときにVCをセットアップして破棄する必要がなくなります。 RSVPにより、受信者は予約を変更し、送信者はトラフィック記述子を動的に変更できます。これは、予約のマージとともに、VCのQoSニーズが変化する状況を作り出す可能性があります。既存のVCのQoSへの変更を許可すると、新しいVCを作成しなくてもこれらの機能が機能するようになります。 ITU-T ATM仕様[24、25]では、一部のセルレートは再ネゴシエートまたは変更できます。具体的には、既存のVCのピークセルレート（PCR）を変更することができ、場合によっては、QoSパラメータがコールセットアップフェーズ中に再ネゴシエートされることがあります。これがIntServモデルのQoS再ネゴシエーションのニーズに十分かどうかは不明です。
The model of one-to-many communications provided by point-to-multipoint VCs does not really match the many-to-many communications provided by IP multicasting. A scaleable mapping from IP multicast addresses to an ATM "group address" can address this problem.
ポイントツーマルチポイントVCによって提供される1対多通信のモデルは、IPマルチキャストによって提供される多対多通信と実際には一致しません。 IPマルチキャストアドレスからATM "グループアドレス"へのスケーラブルなマッピングは、この問題に対処できます。
The MultiProtocol Label Switching (MPLS) working group is discussing methods for optimizing the use of ATM and other switched networks for IP by encapsulating the data with a header that is used by the interior switches to achieve faster forwarding lookups. [22] discusses a framework for this work. It is unclear how this work will affect IntServ and RSVP over label switched networks but there may be some interactions.
MultiProtocol Label Switching（MPLS）ワーキンググループは、内部スイッチで使用されるヘッダーを使用してデータをカプセル化することにより、ATMおよびIPの他のスイッチドネットワークの使用を最適化し、より高速な転送ルックアップを実現する方法について議論しています。 [22]は、この作業のフレームワークについて説明しています。この作業がラベルスイッチドネットワーク上のIntServおよびRSVPにどのように影響するかは不明ですが、いくつかの相互作用がある可能性があります。
RSVP is explicitly not a routing protocol. However, since it conveys QoS information, it may prove to be a valuable input to a routing protocol that can make path determinations based on QoS and network load information. In other words, instead of asking for just the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow if routing has the ability to use this information in order to determine a route. Other forms of QoS routing have existed in the past such as using the IP TOS and Precedence bits to select a path through the network. Some have discussed using these same bits to select one of a set of parallel ATM VCs as a form of QoS routing. ATM routing has also considered the problem of QoS routing through the Private Network-to-Network Interface (PNNI) [26] routing protocol for routing ATM VCs on a path that can support their needs. The work in this area is just starting and there are numerous issues to consider. [23], as part of the work of the QoSR working group frame the issues for QoS Routing in the Internet.
RSVPは明示的にルーティングプロトコルではありません。ただし、QoS情報を伝達するため、QoSとネットワーク負荷情報に基づいてパスを決定できるルーティングプロトコルへの貴重な入力となる場合があります。言い換えれば、ルーティングがルートを決定するためにこの情報を使用する能力を持っている場合、RSVPがフローのQoSニーズに関する情報を提供することは、特定の宛先アドレスのIPネクストホップだけを求める代わりに、価値があるかもしれません。 。ネットワークを通るパスを選択するためにIP TOSおよびPrecedenceビットを使用するなど、QoSルーティングの他の形式は過去に存在していました。これらの同じビットを使用して、QoSルーティングの形式として並列ATM VCのセットの1つを選択することについて説明した人もいます。また、ATMルーティングは、プライベートネットワーク間インターフェイス（PNNI）[26]ルーティングプロトコルを介したQoSルーティングの問題を考慮しており、ATM VCを、そのニーズをサポートできるパスでルーティングします。この領域での作業はまだ始まったばかりであり、考慮すべき多くの問題があります。 [23]、QoSRワーキンググループの作業の一環として、インターネットにおけるQoSルーティングの問題。
RSVP was designed to support both unicast and IP multicast applications. This means that RSVP needs to work closely with multicast and unicast routing. Unicast routing over ATM has been addressed [10] and [11]. MARS [5] provides multicast address resolution for IP over ATM networks, an important part of the solution for multicast but still relies on multicast routing protocols to connect multicast senders and receivers on different subnets.
RSVPは、ユニキャストアプリケーションとIPマルチキャストアプリケーションの両方をサポートするように設計されています。これは、RSVPがマルチキャストおよびユニキャストルーティングと緊密に連携する必要があることを意味します。 ATMを介したユニキャストルーティングは、[10]および[11]で対処されています。 MARS [5]は、IP over ATMネットワークにマルチキャストアドレス解決を提供します。これは、マルチキャストソリューションの重要な部分ですが、マルチキャストルーティングプロトコルに依存して、異なるサブネット上のマルチキャスト送信側と受信側を接続します。
Some of the scaling issues noted in previous sections can be addressed by aggregating several RSVP flows over a single VC if the destinations of the VC match for all the flows being aggregated. However, this causes considerable complexity in the management of VCs and in the scheduling of packets within each VC at the root point of the VC. Note that the rescheduling of flows within a VC is not possible in the switches in the core of the ATM network. Virtual Paths (VPs) can be used for aggregating multiple VCs. This topic is discussed in greater detail as it applies to multicast data distribution in section 4.2.3.4
前のセクションで説明したスケーリングの問題の一部は、VCの宛先が集約されるすべてのフローと一致する場合、単一のVCを介して複数のRSVPフローを集約することで対処できます。ただし、これにより、VCの管理と、VCのルートポイントにある各VC内のパケットのスケジューリングがかなり複雑になります。 ATMネットワークのコアにあるスイッチでは、VC内のフローの再スケジューリングはできないことに注意してください。仮想パス（VP）は、複数のVCを集約するために使用できます。このトピックは、セクション4.2.3.4でマルチキャストデータ配信に適用されるため、より詳細に説明されています。
The mapping of QoS parameters from the IntServ models to the ATM service classes is an important issue in making RSVP and IntServ work over ATM. [14] addresses these issues very completely for the Controlled Load and Guaranteed Service models. An additional issue is that while some guidelines can be developed for mapping the parameters of a given service model to the traffic descriptors of an ATM traffic class, implementation variables, policy, and cost factors can make strict mapping problematic. So, a set of workable mappings that can be applied to different network requirements and scenarios is needed as long as the mappings can satisfy the needs of the service model(s).
IntServモデルからATMサービスクラスへのQoSパラメータのマッピングは、RSVPおよびIntServをATMで機能させる上で重要な問題です。 [14]は、制御された負荷モデルと保証されたサービスモデルについて、これらの問題に非常に完全に対処しています。追加の問題は、特定のサービスモデルのパラメータをATMトラフィッククラスのトラフィック記述子にマッピングするためにいくつかのガイドラインを作成できる一方で、実装変数、ポリシー、およびコスト要因により、厳密なマッピングが問題になる可能性があることです。したがって、マッピングがサービスモデルのニーズを満たすことができる限り、さまざまなネットワーク要件やシナリオに適用できる実用的なマッピングのセットが必要です。
It is obvious that the needs of hosts that are directly connected to ATM networks must be considered for RSVP and IntServ over ATM. Functionality for RSVP over ATM must not assume that an ATM host has all the functionality of a router, but such things as MARS and NHRP clients would be worthwhile features. A host must manage VCs just like any other ATM sender or receiver as described later in section 4.
ATMネットワークに直接接続されているホストのニーズをRSVPとIntServ over ATMで考慮する必要があることは明らかです。 ATM上のRSVPの機能は、ATMホストがルータのすべての機能を備えていると想定してはなりませんが、MARSやNHRPクライアントなどの機能は価値があります。ホストは、セクション4で後述する他のATM送信機または受信機と同様にVCを管理する必要があります。
Since RSVP and IntServ create classes of preferential service, some form of administrative control and/or cost allocation is needed to control access. There are certain types of policies specific to ATM and IP over ATM that need to be studied to determine how they interoperate with the IP and IntServ policies being developed. Typical IP policies would be that only certain users are allowed to make reservations. This policy would translate well to IP over ATM due to the similarity to the mechanisms used for Call Admission Control (CAC).
RSVPとIntServは優先サービスのクラスを作成するため、アクセスを制御するには、何らかの形の管理制御やコストの割り当てが必要です。開発中のIPおよびIntServポリシーと相互運用する方法を決定するために調査する必要があるATMおよびIP over ATMに固有の特定のタイプのポリシーがあります。一般的なIPポリシーでは、特定のユーザーのみが予約を許可されます。このポリシーは、コールアドミッション制御（CAC）に使用されるメカニズムに類似しているため、IP over ATMにうまく変換されます。
There may be a need for policies specific to IP over ATM. For example, since signalling costs in ATM are high relative to IP, an IP over ATM specific policy might restrict the ability to change the prevailing QoS in a VC. If VCs are relatively scarce, there also might be specific accounting costs in creating a new VC. The work so far has been preliminary, and much work remains to be done. The policy mechanisms outlined in [12] and [13] provide the basic mechanisms for implementing policies for RSVP and IntServ over any media, not just ATM.
IP over ATMに固有のポリシーが必要になる場合があります。たとえば、ATMのシグナリングコストはIPに比べて高いため、IP over ATM固有のポリシーは、VCでの一般的なQoSを変更する機能を制限する可能性があります。 VCが比較的少ない場合、新しいVCの作成に特定の会計コストがかかる可能性もあります。これまでの作業は予備的なものであり、まだ多くの作業が行われていません。 [12]と[13]で概説されているポリシーメカニズムは、ATMだけでなく、あらゆるメディア上でRSVPとIntServのポリシーを実装するための基本的なメカニズムを提供します。
Now that we have defined some of the issues for IntServ and RSVP over ATM, we can formulate a framework for solutions. The problem breaks down to two very distinct areas; the mapping of IntServ models to ATM service categories and QoS parameters and the operation of RSVP over ATM.
IntServとRSVP over ATMのいくつかの問題を定義したので、ソリューションのフレームワークを作成できます。問題は2つの非常に異なる領域に分類されます。 IntServモデルのATMサービスカテゴリとQoSパラメータへのマッピング、RSVP over ATMの操作。
Mapping IntServ models to ATM service categories and QoS parameters is a matter of determining which categories can support the goals of the service models and matching up the parameters and variables between the IntServ description and the ATM description(s). Since ATM has such a wide variety of service categories and parameters, more than one ATM service category should be able to support each of the two IntServ models. This will provide a good bit of flexibility in configuration and deployment. [14] examines this topic completely.
IntServモデルをATMサービスカテゴリとQoSパラメータにマッピングすることは、サービスモデルの目標をサポートできるカテゴリを決定し、IntServの説明とATMの説明の間でパラメータと変数を照合することです。 ATMにはさまざまなサービスカテゴリとパラメータがあるため、複数のATMサービスカテゴリが2つのIntServモデルのそれぞれをサポートできるはずです。これにより、構成と展開にかなりの柔軟性が提供されます。 [14]はこのトピックを完全に調べます。
The operation of RSVP over ATM requires careful management of VCs in order to match the dynamics of the RSVP protocol. VCs need to be managed for both the RSVP QoS data and the RSVP signalling messages. The remainder of this document will discuss several approaches to managing VCs for RSVP and [15] and [16] discuss their application for implementations in term of interoperability requirement and implementation guidelines.
RSVP over ATMの操作では、RSVPプロトコルのダイナミクスと一致させるために、VCを慎重に管理する必要があります。 VCは、RSVP QoSデータとRSVPシグナリングメッセージの両方に対して管理する必要があります。このドキュメントの残りの部分では、RSVPのVCを管理するためのいくつかのアプローチについて説明し、[15]と[16]は、相互運用性の要件と実装ガイドラインの観点から、それらの実装への適用について説明します。
This section provides more detail on the issues related to the management of SVCs for RSVP and IntServ.
このセクションでは、RSVPおよびIntServのSVCの管理に関連する問題について詳しく説明します。
As discussed in section 2.1.1.2, there is an apparent mismatch between RSVP and ATM. Specifically, RSVP control is receiver oriented and ATM control is sender oriented. This initially may seem like a major issue, but really is not. While RSVP reservation (RESV) requests are generated at the receiver, actual allocation of resources takes place at the subnet sender. For data flows, this means that subnet senders will establish all QoS VCs and the subnet receiver must be able to accept incoming QoS VCs, as illustrated in Figure 1. These restrictions are consistent with RSVP version 1 processing rules and allow senders to use different flow to VC mappings and even different QoS renegotiation techniques without interoperability problems.
セクション2.1.1.2で説明したように、RSVPとATMの間には明らかな不一致があります。具体的には、RSVP制御は受信者指向であり、ATM制御は送信者指向です。これは最初は大きな問題のように思えるかもしれませんが、実際にはそうではありません。 RSVP予約（RESV）要求は受信側で生成されますが、リソースの実際の割り当てはサブネット送信側で行われます。データフローの場合、これは、図1に示すように、サブネットセンダーがすべてのQoS VCを確立し、サブネットレシーバーが着信QoS VCを受け入れることができる必要があることを意味します。これらの制限はRSVPバージョン1処理ルールと一致し、送信者が異なるフローを使用できるようにします相互運用性の問題のないVCマッピングおよびさまざまなQoS再ネゴシエーションテクニックにさえ。
The use of the reverse path provided by point-to-point VCs by receivers is for further study. There are two related issues. The first is that use of the reverse path requires the VC initiator to set appropriate reverse path QoS parameters. The second issue is that reverse paths are not available with point-to-multipoint VCs, so reverse paths could only be used to support unicast RSVP reservations.
ポイントツーポイントVCがレシーバーによって提供するリバースパスの使用は、今後の検討課題です。 2つの関連する問題があります。 1つ目は、リバースパスを使用するには、VCイニシエーターが適切なリバースパスQoSパラメータを設定する必要があることです。 2番目の問題は、ポイントツーマルチポイントVCではリバースパスを使用できないため、リバースパスはユニキャストRSVP予約をサポートするためにのみ使用できるということです。
Any RSVP over ATM implementation must map RSVP and RSVP associated data flows to ATM Virtual Circuits (VCs). LAN Emulation [17], Classical IP [10] and, more recently, NHRP [4] discuss mapping IP traffic onto ATM SVCs, but they only cover a single QoS class, i.e., best effort traffic. When QoS is introduced, VC mapping must be revisited. For RSVP controlled QoS flows, one issue is VCs to use for QoS data flows.
RSVP over ATMの実装では、RSVPおよびRSVP関連のデータフローをATM Virtual Circuits（VC）にマッピングする必要があります。 LANエミュレーション[17]、クラシカルIP [10]、そして最近ではNHRP [4]は、ATM SVCへのIPトラフィックのマッピングについて説明していますが、それらは単一のQoSクラス、つまりベストエフォートトラフィックのみをカバーしています。 QoSが導入されたら、VCマッピングを再検討する必要があります。 RSVPで制御されるQoSフローの場合、1つの問題はQoSデータフローに使用するVCです。
In the Classic IP over ATM and current NHRP models, a single point-to-point VC is used for all traffic between two ATM attached hosts (routers and end-stations). It is likely that such a single VC will not be adequate or optimal when supporting data flows with multiple .bp QoS types. RSVP's basic purpose is to install support for flows with multiple QoS types, so it is essential for any RSVP over ATM solution to address VC usage for QoS data flows, as shown in Figure 1.
クラシックIP over ATMおよび現在のNHRPモデルでは、2つのATM接続ホスト（ルーターと端末）間のすべてのトラフィックに単一のポイントツーポイントVCが使用されます。複数の.bp QoSタイプのデータフローをサポートする場合、そのような単一のVCは適切または最適ではない可能性があります。 RSVPの基本的な目的は、複数のQoSタイプのフローのサポートをインストールすることです。そのため、図1に示すように、RSVP over ATMソリューションでは、QoSデータフローのVC使用に対処することが不可欠です。
RSVP reservation styles must also be taken into account in any VC usage strategy.
RSVP予約スタイルも、すべてのVC使用戦略で考慮する必要があります。
This section describes issues and methods for management of VCs associated with QoS data flows. When establishing and maintaining VCs, the subnet sender will need to deal with several complicating factors including multiple QoS reservations, requests for QoS changes, ATM short-cuts, and several multicast specific issues. The multicast specific issues result from the nature of ATM connections. The key multicast related issues are heterogeneity, data distribution, receiver transitions, and end-point identification.
このセクションでは、QoSデータフローに関連するVCの管理に関する問題と方法について説明します。 VCを確立して維持するとき、サブネット送信者は、複数のQoS予約、QoS変更の要求、ATMショートカット、およびいくつかのマルチキャスト固有の問題を含む、いくつかの複雑な要素に対処する必要があります。マルチキャスト固有の問題は、ATM接続の性質に起因します。マルチキャスト関連の主要な問題は、異質性、データ配信、レシーバーの移行、エンドポイントの識別です。
There are various approaches available for mapping reservations on to VCs. A distinguishing attribute of all approaches is how reservations are combined on to individual VCs. When mapping reservations on to VCs, individual VCs can be used to support a single reservation, or reservation can be combined with others on to
予約をVCにマッピングするには、さまざまな方法があります。すべてのアプローチの際立った属性は、個々のVCで予約を組み合わせる方法です。予約をVCにマッピングする場合、個々のVCを使用して単一の予約をサポートするか、予約を他のVCと組み合わせることができます。
"aggregate" VCs. In the first case, each reservation will be supported by one or more VCs. Multicast reservation requests may translate into the setup of multiple VCs as is described in more detail in section 4.2.2. Unicast reservation requests will always translate into the setup of a single QoS VC. In both cases, each VC will only carry data associated with a single reservation. The greatest benefit if this approach is ease of implementation, but it comes at the cost of increased (VC) setup time and the consumption of greater number of VC and associated resources.
「集約」VC。最初のケースでは、各予約は1つ以上のVCによってサポートされます。マルチキャスト予約要求は、セクション4.2.2で詳細に説明されているように、複数のVCのセットアップに変換される場合があります。ユニキャスト予約要求は、常に単一のQoS VCのセットアップに変換されます。どちらの場合も、各VCは単一の予約に関連付けられたデータのみを伝送します。このアプローチが実装の容易さである場合の最大の利点は、増加した（VC）セットアップ時間と、より多くのVCおよび関連リソースの消費という犠牲になります。
When multiple reservations are combined onto a single VC, it is referred to as the "aggregation" model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem (section 4.2.2) in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem (section 4.2.7) for ATM has also been reduced to a solved problem.
複数の予約が1つのVCに結合される場合、それは「集約」モデルと呼ばれます。このモデルでは、ATMネットワークのIPルーターとホストの間に大きなVCを設定できます。これらのVCは、IP統合サービス（IIS）ポイントツーポイントリンク（T-1、DS-3など）が現在管理されているように管理できます。複数のRSVPセッションを介した複数のソースからのトラフィックは、同じVCで多重化される場合があります。このアプローチには多くの利点があります。第1に、トラフィックが流れ始めたときにVCが存在するので、通常はシグナリング遅延がないため、VCの設定に時間を浪費することはありません。第二に、ATM全体の不均一性の問題（セクション4.2.2）は、解決された問題に削減されました。最後に、ATMの動的QoS問題（セクション4.2.7）も解決された問題になりました。
The aggregation model can be used with point-to-point and point-to-multipoint VCs. The problem with the aggregation model is that the choice of what QoS to use for the VCs may be difficult, without knowledge of the likely reservation types and sizes but is made easier since the VCs can be changed as needed.
集約モデルは、ポイントツーポイントおよびポイントツーマルチポイントVCで使用できます。集約モデルの問題は、VCに使用するQoSの選択が、可能性のある予約タイプとサイズを知らない場合は難しいかもしれませんが、VCは必要に応じて変更できるため、より簡単になることです。
Unicast data VC management is much simpler than multicast data VC management but there are still some similar issues. If one considers unicast to be a devolved case of multicast, then implementing the multicast solutions will cover unicast. However, some may want to consider unicast-only implementations. In these situations, the choice of using a single flow per VC or aggregation of flows onto a single VC remains but the problem of heterogeneity discussed in the following section is removed.
ユニキャストデータVCの管理は、マルチキャストデータVCの管理よりもはるかに簡単ですが、同様の問題がいくつかあります。ユニキャストがマルチキャストのデボルブケースであると考える場合、マルチキャストソリューションの実装はユニキャストをカバーします。ただし、ユニキャストのみの実装を検討したい場合もあります。これらの状況では、VCごとに単一のフローを使用するか、単一のVCにフローを集約するかの選択は残りますが、次のセクションで説明する異質性の問題は取り除かれます。
As mentioned in section 2.1.3.1 and shown in figure 2, multicast heterogeneity occurs when receivers request different qualities of service within a single session. This means that the amount of requested resources differs on a per next hop basis. A related type of heterogeneity occurs due to best-effort receivers. In any IP multicast group, it is possible that some receivers will request QoS (via RSVP) and some receivers will not. In shared media networks, like Ethernet, receivers that have not requested resources can typically be given identical service to those that have without complications. This is not the case with ATM. In ATM networks, any additional end-points of a VC must be explicitly added. There may be costs associated with adding the best-effort receiver, and there might not be adequate resources. An RSVP over ATM solution will need to support heterogeneous receivers even though ATM does not currently provide such support directly.
セクション2.1.3.1で説明し、図2に示すように、マルチキャストの異質性は、受信者が単一のセッション内で異なるサービス品質を要求したときに発生します。つまり、要求されるリソースの量は、ネクストホップごとに異なります。関連するタイプの異質性は、ベストエフォートレシーバーが原因で発生します。どのIPマルチキャストグループでも、一部のレシーバーは（RSVPを介して）QoSを要求し、一部のレシーバーはQoSを要求しない可能性があります。イーサネットなどの共有メディアネットワークでは、リソースを要求していない受信者に、通常、問題のない受信者と同じサービスを提供できます。これは、ATMには当てはまりません。 ATMネットワークでは、VCの追加のエンドポイントを明示的に追加する必要があります。ベストエフォートレシーバーの追加に関連するコストがあり、十分なリソースがない可能性があります。 ATMが現在そのようなサポートを直接提供していない場合でも、RSVP over ATMソリューションは、異種レシーバーをサポートする必要があります。
RSVP heterogeneity is supported over ATM in the way RSVP reservations are mapped into ATM VCs. There are four alternative approaches this mapping. There are multiple models for supporting RSVP heterogeneity over ATM. Section 4.2.3.1 examines the multiple VCs per RSVP reservation (or full heterogeneity) model where a single reservation can be forwarded onto several VCs each with a different QoS. Section 4.2.3.2 presents a limited heterogeneity model where exactly one QoS VC is used along with a best effort VC. Section 4.2.3.3 examines the VC per RSVP reservation (or homogeneous) model, where each RSVP reservation is mapped to a single ATM VC. Section 4.2.3.4 describes the aggregation model allowing aggregation of multiple RSVP reservations into a single VC.
RSVP予約がATM VCにマッピングされる方法で、RSVPの異質性がATMでサポートされます。このマッピングには4つの代替アプローチがあります。 ATMを介したRSVPの異質性をサポートするための複数のモデルがあります。セクション4.2.3.1は、RSVP予約（または完全な異質性）ごとに複数のVCを検証します。このモデルでは、単一の予約を、それぞれ異なるQoSを持つ複数のVCに転送できます。セクション4.2.3.2は、ベストエフォートVCとともに正確に1つのQoS VCが使用される限定的な異機種モデルを示しています。 4.2.3.3節では、RSVP予約（または同種）ごとのVCモデルを調べます。各RSVP予約は単一のATM VCにマップされます。セクション4.2.3.4では、複数のRSVP予約を単一のVCに集約できる集約モデルについて説明しています。
RSVP supports heterogeneous QoS, meaning that different receivers of the same multicast group can request a different QoS. But importantly, some receivers might have no reservation at all and want to receive the traffic on a best effort service basis. The IP model allows receivers to join a multicast group at any time on a best effort basis, and it is important that ATM as part of the Internet continue to provide this service. We define the "full heterogeneity" model as providing a separate VC for each distinct QoS for a multicast session including best effort and one or more qualities of service.
RSVPは異種QoSをサポートしています。つまり、同じマルチキャストグループの異なる受信者が異なるQoSを要求できます。しかし重要なのは、一部のレシーバーはまったく予約を持たず、ベストエフォートサービスベースでトラフィックを受信したい場合があることです。 IPモデルにより、受信者はいつでもベストエフォートベースでマルチキャストグループに参加できます。インターネットの一部としてのATMがこのサービスを提供し続けることが重要です。 「完全な異種性」モデルは、ベストエフォートと1つ以上のサービス品質を含む、マルチキャストセッションの個別のQoSごとに個別のVCを提供するものとして定義します。
Note that while full heterogeneity gives users exactly what they request, it requires more resources of the network than other possible approaches. The exact amount of bandwidth used for duplicate traffic depends on the network topology and group membership.
完全な異質性はユーザーが要求するものを正確に提供しますが、他の可能なアプローチよりも多くのネットワークリソースを必要とします。重複トラフィックに使用される正確な帯域幅は、ネットワークトポロジとグループメンバーシップによって異なります。
We define the "limited heterogeneity" model as the case where the receivers of a multicast session are limited to use either best effort service or a single alternate quality of service. The alternate QoS can be chosen either by higher level protocols or by dynamic renegotiation of QoS as described below.
「制限付きの異質性」モデルは、マルチキャストセッションの受信者がベストエフォートサービスまたは単一の代替サービス品質のいずれかを使用するように制限されている場合と定義します。代替QoSは、より高いレベルのプロトコルまたは以下で説明するQoSの動的再ネゴシエーションのいずれかによって選択できます。
In order to support limited heterogeneity, each ATM edge device participating in a session would need at most two VCs. One VC would be a point-to-multipoint best effort service VC and would serve all best effort service IP destinations for this RSVP session.
限られた異種性をサポートするために、セッションに参加する各ATMエッジデバイスには、最大2つのVCが必要です。 1つのVCはポイントツーマルチポイントのベストエフォートサービスVCであり、このRSVPセッションのすべてのベストエフォートサービスIP宛先に対応します。
The other VC would be a point to multipoint VC with QoS and would serve all IP destinations for this RSVP session that have an RSVP reservation established.
他のVCはQoSを備えたポイントツーマルチポイントVCであり、RSVP予約が確立されているこのRSVPセッションのすべてのIP宛先に対応します。
As with full heterogeneity, a disadvantage of the limited heterogeneity scheme is that each packet will need to be duplicated at the network layer and one copy sent into each of the 2 VCs. Again, the exact amount of excess traffic will depend on the network topology and group membership. If any of the existing QoS VC end-points cannot upgrade to the new QoS, then the new reservation fails though the resources exist for the new receiver.
完全な不均一性と同様に、制限された不均一性スキームの欠点は、各パケットをネットワーク層で複製し、1つのコピーを2つのVCのそれぞれに送信する必要があることです。この場合も、超過トラフィックの正確な量は、ネットワークトポロジとグループメンバーシップによって異なります。既存のQoS VCエンドポイントのいずれかが新しいQoSにアップグレードできない場合、新しい受信機用のリソースは存在しますが、新しい予約は失敗します。
We define the "homogeneous" model as the case where all receivers of a multicast session use a single quality of service VC. Best-effort receivers also use the single RSVP triggered QoS VC. The single VC can be a point-to-point or point-to-multipoint as appropriate. The QoS VC is sized to provide the maximum resources requested by all RSVP next- hops.
「同種」モデルは、マルチキャストセッションのすべての受信者が単一のサービス品質VCを使用する場合として定義されています。ベストエフォートレシーバーも、単一のRSVPトリガーQoS VCを使用します。単一のVCは、必要に応じてポイントツーポイントまたはポイントツーマルチポイントにすることができます。 QoS VCは、すべてのRSVPネクストホップによって要求される最大のリソースを提供できるサイズになっています。
This model matches the way the current RSVP specification addresses heterogeneous requests. The current processing rules and traffic control interface describe a model where the largest requested reservation for a specific outgoing interface is used in resource allocation, and traffic is transmitted at the higher rate to all next-hops. This approach would be the simplest method for RSVP over ATM implementations.
このモデルは、現在のRSVP仕様が異種の要求に対処する方法と一致します。現在の処理ルールとトラフィック制御インターフェイスは、特定の発信インターフェイスに対して要求された最大の予約がリソース割り当てに使用され、トラフィックがすべてのネクストホップに高いレートで送信されるモデルを記述しています。このアプローチは、RSVP over ATM実装の最も簡単な方法です。
While this approach is simple to implement, providing better than best-effort service may actually be the opposite of what the user desires. There may be charges incurred or resources that are wrongfully allocated. There are two specific problems. The first problem is that a user making a small or no reservation would share a QoS VC resources without making (and perhaps paying for) an RSVP reservation. The second problem is that a receiver may not receive any data. This may occur when there is insufficient resources to add a receiver. The rejected user would not be added to the single VC and it would not even receive traffic on a best effort basis.
このアプローチは簡単に実装できますが、ベストエフォートサービスよりも優れたサービスを提供することは、実際にはユーザーの希望とは逆になる場合があります。料金が発生したり、リソースが誤って割り当てられたりする場合があります。 2つの特定の問題があります。最初の問題は、小さな予約を行うか、予約を行わないユーザーは、RSVP予約を行わずに（そしておそらく支払うことなく）QoS VCリソースを共有することです。 2番目の問題は、受信者がデータを受信しない可能性があることです。これは、レシーバーを追加するのに十分なリソースがない場合に発生する可能性があります。拒否されたユーザーは単一のVCに追加されず、ベストエフォートベースでトラフィックを受信することもできません。
Not sending data traffic to best-effort receivers because of another receiver's RSVP request is clearly unacceptable. The previously described limited heterogeneous model ensures that data is always sent to both QoS and best-effort receivers, but it does so by requiring replication of data at the sender in all cases. It is possible to extend the homogeneous model to both ensure that data is always sent to best-effort receivers and also to avoid replication in the normal case. This extension is to add special handling for the case where a best- effort receiver cannot be added to the QoS VC. In this case, a best effort VC can be established to any receivers that could not be added to the QoS VC. Only in this special error case would senders be required to replicate data. We define this approach as the "modified homogeneous" model.
別の受信者のRSVP要求が明らかに受け入れられないため、ベストエフォートの受信者にデータトラフィックを送信しない。前述の限定的な異種モデルでは、データは常にQoSとベストエフォートの受信者の両方に送信されますが、送信者でのデータの複製をすべての場合に要求することで送信されます。同種モデルを拡張して、データが常にベストエフォートのレシーバーに送信されるようにすることと、通常の場合の複製を回避することの両方が可能です。この拡張は、ベストエフォートレシーバーをQoS VCに追加できない場合の特別な処理を追加するためのものです。この場合、QoS VCに追加できなかった受信者に対して、ベストエフォートVCを確立できます。この特別なエラーの場合のみ、送信者はデータを複製する必要があります。このアプローチを「修正均質」モデルと定義します。
The last scheme is the multiple RSVP reservations per VC (or aggregation) model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem for ATM has also been reduced to a solved problem. This approach can be used with point-to-point and point-to-multipoint VCs. The problem with the aggregation approach is that the choice of what QoS to use for which of the VCs is difficult, but is made easier if the VCs can be changed as needed.
最後のスキームは、VC（または集約）モデルごとの複数のRSVP予約です。このモデルでは、ATMネットワークのIPルーターとホストの間に大きなVCを設定できます。これらのVCは、IP統合サービス（IIS）ポイントツーポイントリンク（T-1、DS-3など）が現在管理されているように管理できます。複数のRSVPセッションを介した複数のソースからのトラフィックは、同じVCで多重化される場合があります。このアプローチには多くの利点があります。第1に、トラフィックが流れ始めたときにVCが存在するので、通常はシグナリング遅延がないため、VCの設定に時間を浪費することはありません。第2に、ATM全体での不均一性の問題は、解決された問題に削減されました。最後に、ATMの動的QoS問題も解決された問題に削減されました。このアプローチは、ポイントツーポイントおよびポイントツーマルチポイントVCで使用できます。集約アプローチの問題は、どのQoSをどのVCに使用するかを選択するのは難しいですが、必要に応じて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 provide QoS end-points, but not best-effort end-points. Another issue is identifying end-points of multicast traffic handled by non-RSVP capable next-hops. In this case a PATH message travels through a non-RSVP egress router on the way to the next hop RSVP node. When the next hop RSVP node sends a RESV message it may arrive at the source over a different route than what the data is using. The source will get the RESV message, but will not know which egress router needs the QoS. For unicast sessions, there is no problem since the ATM end-point will be the IP next-hop router. Unfortunately, multicast routing may not be able to uniquely identify the IP next-hop router. So it is possible that a multicast end-point can not be identified.
実装では、IPマルチキャストグループに参加しているATMエンドポイントを識別できる必要があります。 ATMエンドポイントは、IPマルチキャストレシーバーまたはネクストホップ、あるいはその両方になります。 QoSとベストエフォートの両方のエンドポイントを特定する必要があります。 RSVPネクストホップ情報はQoSエンドポイントを提供しますが、ベストエフォートエンドポイントを提供しません。別の問題は、RSVP非対応のネクストホップによって処理されるマルチキャストトラフィックのエンドポイントを識別することです。この場合、PATHメッセージは、ネクストホップのRSVPノードに向かう途中で、非RSVP出力ルーターを通過します。ネクストホップRSVPノードがRESVメッセージを送信すると、データが使用しているものとは異なるルートを介して送信元に到着する場合があります。ソースはRESVメッセージを受け取りますが、QoSを必要とする出力ルーターはわかりません。ユニキャストセッションの場合、ATMエンドポイントがIPネクストホップルータになるため、問題はありません。残念ながら、マルチキャストルーティングでは、IPネクストホップルーターを一意に識別できない場合があります。そのため、マルチキャストエンドポイントを識別できない可能性があります。
In the most common case, MARS will be used to identify all end-points of a multicast group. In the router to router case, a multicast routing protocol may provide all next-hops for a particular multicast group. In either case, RSVP over ATM implementations must obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms. The full list can be compared against the RSVP identified end-points to determine the list of best-effort receivers. There is no straightforward solution to uniquely identifying end-points of multicast traffic handled by non-RSVP next hops. The preferred solution is to use multicast routing protocols that support unique end-point identification. In cases where such routing protocols are unavailable, all IP routers that will be used to support RSVP over ATM should support RSVP. To ensure proper behavior, implementations should, by default, only establish RSVP-initiated VCs to RSVP capable end-points.
最も一般的なケースでは、MARSを使用して、マルチキャストグループのすべてのエンドポイントを識別します。ルーターツールーターの場合、マルチキャストルーティングプロトコルは、特定のマルチキャストグループにすべてのネクストホップを提供できます。どちらの場合も、RSVP over ATM実装は、適切なメカニズムを使用して、QoSと非QoSの両方のエンドポイントの完全なリストを取得する必要があります。完全なリストをRSVPで識別されたエンドポイントと比較して、ベストエフォートレシーバーのリストを決定できます。非RSVPネクストホップによって処理されるマルチキャストトラフィックのエンドポイントを一意に識別する簡単なソリューションはありません。推奨されるソリューションは、一意のエンドポイント識別をサポートするマルチキャストルーティングプロトコルを使用することです。そのようなルーティングプロトコルが利用できない場合、RSVP over ATMをサポートするために使用されるすべてのIPルーターはRSVPをサポートする必要があります。適切な動作を保証するために、実装では、デフォルトで、RSVPが開始したVCのみをRSVP対応のエンドポイントに確立する必要があります。
Two models are planned for IP multicast data distribution over ATM. In one model, senders establish point-to-multipoint VCs to all ATM attached destinations, and data is then sent over these VCs. This model is often called "multicast mesh" or "VC mesh" mode distribution. In the second model, senders send data over point-to-point VCs to a central point and the central point relays the data onto point-to-multipoint VCs that have been established to all receivers of the IP multicast group. This model is often referred to as "multicast server" mode distribution. RSVP over ATM solutions must ensure that IP multicast data is distributed with appropriate QoS.
ATMを介したIPマルチキャストデータ配信には、2つのモデルが計画されています。 1つのモデルでは、送信側がすべてのATM接続先にポイントツーマルチポイントVCを確立し、データはこれらのVCを介して送信されます。このモデルは、「マルチキャストメッシュ」または「VCメッシュ」モードの配布と呼ばれることがよくあります。 2番目のモデルでは、送信者はポイントツーポイントVCを介して中央ポイントにデータを送信し、中央ポイントはIPマルチキャストグループのすべての受信者に確立されているポイントツーマルチポイントVCにデータを中継します。このモデルは、「マルチキャストサーバー」モードの配布と呼ばれることがよくあります。 RSVP over ATMソリューションでは、IPマルチキャストデータが適切なQoSで配信されるようにする必要があります。
In the Classical IP context, multicast server support is provided via MARS [5]. MARS does not currently provide a way to communicate QoS requirements to a MARS multicast server. Therefore, RSVP over ATM implementations must, by default, support "mesh-mode" distribution for RSVP controlled multicast flows. When using multicast servers that do not support QoS requests, a sender must set the service, not global, break bit(s).
従来のIPのコンテキストでは、マルチキャストサーバーのサポートはMARSを介して提供されます[5]。 MARSは現在、QoS要件をMARSマルチキャストサーバーに通信する方法を提供していません。したがって、RSVP over ATM実装は、デフォルトで、RSVP制御のマルチキャストフローの「メッシュモード」配信をサポートする必要があります。 QoS要求をサポートしないマルチキャストサーバーを使用する場合、送信者はグローバルではなくサービスにブレークビットを設定する必要があります。
When setting up a point-to-multipoint VCs for multicast RSVP sessions, there will be a time when some receivers have been added to a QoS VC and some have not. During such transition times it is possible to start sending data on the newly established VC. The issue is when to start send data on the new VC. If data is sent both on the new VC and the old VC, then data will be delivered with proper QoS to some receivers and with the old QoS to all receivers. This means the QoS receivers can get duplicate data. If data is sent just on the new QoS VC, the receivers that have not yet been added will lose information. So, the issue comes down to whether to send to both the old and new VCs, or to send to just one of the VCs. In one case duplicate information will be received, in the other some information may not be received.
マルチキャストRSVPセッション用にポイントツーマルチポイントVCを設定する場合、QoS VCに追加されているレシーバと追加されていないレシーバがある場合があります。そのような移行時間中に、新しく確立されたVCでデータの送信を開始することが可能です。問題は、新しいVCでデータの送信をいつ開始するかです。データが新しいVCと古いVCの両方で送信された場合、データは適切なQoSで一部のレシーバーに配信され、古いQoSですべてのレシーバーに配信されます。つまり、QoSレシーバーは重複したデータを取得できます。新しいQoS VCでのみデータが送信される場合、まだ追加されていない受信者は情報を失います。したがって、問題は古いVCと新しいVCの両方に送信するか、VCの1つだけに送信するかによって決まります。重複した情報が受信される場合と、受信されない場合があります。
This issue needs to be considered for three cases:
この問題は、次の3つの場合について考慮する必要があります。
- When establishing the first QoS VC - When establishing a VC to support a QoS change - When adding a new end-point to an already established QoS VC
- 最初のQoS VCを確立するとき-QoSの変更をサポートするVCを確立するとき-すでに確立されているQoS VCに新しいエンドポイントを追加するとき
The first two cases are very similar. It both, it is possible to send data on the partially completed new VC, and the issue of duplicate versus lost information is the same. The last case is when an end-point must be added to an existing QoS VC. In this case the end-point must be both added to the QoS VC and dropped from a best-effort VC. The issue is which to do first. If the add is first requested, then the end-point may get duplicate information. If the drop is requested first, then the end-point may loose information.
最初の2つのケースは非常に似ています。両方とも、部分的に完成した新しいVCでデータを送信することが可能であり、情報の重複と消失の問題は同じです。最後のケースは、エンドポイントを既存のQoS VCに追加する必要がある場合です。この場合、エンドポイントは両方ともQoS VCに追加され、ベストエフォートVCからドロップされる必要があります。問題は、最初に何をするかです。追加が最初に要求された場合、エンドポイントは重複した情報を取得する可能性があります。ドロップが最初に要求された場合、エンドポイントは情報を失う可能性があります。
In order to ensure predictable behavior and delivery of data to all receivers, data can only be sent on a new VCs once all parties have been added. This will ensure that all data is only delivered once to all receivers. This approach does not quite apply for the last case. In the last case, the add operation should be completed first, then the drop operation. This means that receivers must be prepared to receive some duplicate packets at times of QoS setup.
予測可能な動作とすべての受信者へのデータの配信を保証するために、データはすべてのパーティが追加された後でのみ新しいVCで送信できます。これにより、すべてのデータがすべての受信者に1回だけ配信されます。このアプローチは、最後のケースにはまったく当てはまりません。最後のケースでは、追加操作を最初に完了してから、ドロップ操作を完了する必要があります。これは、QoSセットアップ時にいくつかの重複パケットを受信するためにレシーバーを準備する必要があることを意味します。
RSVP provides dynamic quality of service (QoS) in that the resources that are requested may change at any time. There are several common reasons for a change of reservation QoS.
RSVPは、要求されたリソースがいつでも変更される可能性があるという点で、動的なサービス品質（QoS）を提供します。予約QoSの変更には、いくつかの一般的な理由があります。
1. An existing receiver can request a new larger (or smaller) QoS. 2. A sender may change its traffic specification (TSpec), which can trigger a change in the reservation requests of the receivers. 3. A new sender can start sending to a multicast group with a larger traffic specification than existing senders, triggering larger reservations. 4. A new receiver can make a reservation that is larger than existing reservations.
1. 既存のレシーバーは、新しい（またはより小さい）QoSを要求できます。 2.送信者は、トラフィック仕様（TSpec）を変更できます。これにより、受信者の予約要求が変更される可能性があります。 3.新しい送信者は、既存の送信者よりもトラフィック仕様が大きいマルチキャストグループへの送信を開始して、より大きな予約をトリガーできます。 4.新しい受信者は、既存の予約よりも大きな予約を行うことができます。
If the limited heterogeneity model is being used and the merge node for the larger reservation is an ATM edge device, a new larger reservation must be set up across the ATM network. Since ATM service, as currently defined in UNI 3.x and UNI 4.0, does not allow renegotiating the QoS of a VC, dynamically changing the reservation means creating a new VC with the new QoS, and tearing down an established VC. Tearing down a VC and setting up a new VC in ATM are complex operations that involve a non-trivial amount of processing time, and may have a substantial latency. There are several options for dealing with this mismatch in service. A specific approach will need to be a part of any RSVP over ATM solution.
制限された異種混合モデルが使用されており、より大きな予約のマージノードがATMエッジデバイスである場合、ATMネットワーク全体で新しいより大きな予約をセットアップする必要があります。現在UNI 3.xおよびUNI 4.0で定義されているATMサービスでは、VCのQoSの再ネゴシエーションが許可されないため、予約を動的に変更すると、新しいQoSで新しいVCが作成され、確立されたVCが破棄されます。 VCの破棄とATMでの新しいVCの設定は複雑な操作であり、処理時間はそれほど大きくなく、かなりの遅延が発生する可能性があります。このサービスの不一致に対処するには、いくつかのオプションがあります。特定のアプローチは、RSVP over ATMソリューションの一部である必要があります。
The default method for supporting changes in RSVP reservations is to attempt to replace an existing VC with a new appropriately sized VC. During setup of the replacement VC, the old VC must be left in place unmodified. The old VC is left unmodified to minimize interruption of QoS data delivery. Once the replacement VC is established, data transmission is shifted to the new VC, and the old VC is then closed. If setup of the replacement VC fails, then the old QoS VC should continue to be used. When the new reservation is greater than the old reservation, the reservation request should be answered with an error. When the new reservation is less than the old reservation, the request should be treated as if the modification was successful. While leaving the larger allocation in place is suboptimal, it maximizes delivery of service to the user. Implementations should retry replacing the too large VC after some appropriate elapsed time.
RSVP予約の変更をサポートするデフォルトの方法は、既存のVCを適切なサイズの新しいVCで置き換えようとすることです。交換用VCのセットアップ中、古いVCは変更せずにそのまま残しておく必要があります。 QoSデータ配信の中断を最小限に抑えるために、古いVCは変更されません。交換用VCが確立されると、データ送信は新しいVCにシフトされ、古いVCは閉じられます。交換用VCのセットアップが失敗した場合、古いQoS VCを引き続き使用する必要があります。新しい予約が古い予約よりも大きい場合、予約リクエストはエラーで応答されます。新しい予約が古い予約より少ない場合、リクエストは変更が成功したかのように処理する必要があります。より大きな割り当てをそのままにしておくことは最適ではありませんが、ユーザーへのサービスの提供を最大化します。実装では、適切な経過時間が経過した後、大きすぎるVCの交換を再試行する必要があります。
One additional issue is that only one QoS change can be processed at one time per reservation. If the (RSVP) requested QoS is changed while the first replacement VC is still being setup, then the replacement VC is released and the whole VC replacement process is restarted. To limit the number of changes and to avoid excessive signalling load, implementations may limit the number of changes that will be processed in a given period. One implementation approach would have each ATM edge device configured with a time parameter T (which can change over time) that gives the minimum amount of time the edge device will wait between successive changes of the QoS of a particular VC. Thus if the QoS of a VC is changed at time t, all messages that would change the QoS of that VC that arrive before time t+T would be queued. If several messages changing the QoS of a VC arrive during the interval, redundant messages can be discarded. At time t+T, the remaining change(s) of QoS, if any, can be executed. This timer approach would apply more generally to any network structure, and might be worthwhile to incorporate into RSVP.
1つの追加の問題は、予約ごとに一度に1つのQoS変更しか処理できないことです。最初の交換用VCのセットアップ中に（RSVP）要求されたQoSが変更されると、交換用VCが解放され、VC交換プロセス全体が再開されます。変更の数を制限し、過度のシグナリング負荷を回避するために、実装では、所定の期間に処理される変更の数を制限する場合があります。 1つの実装アプローチでは、特定のVCのQoSの連続した変更の間にエッジデバイスが待機する最小時間を与える時間パラメータT（時間とともに変化する可能性があります）で構成された各ATMエッジデバイスを使用します。したがって、VCのQoSが時間tに変更されると、時間VCのQoSを変更するすべてのメッセージが時間t + Tより前に到着し、キューに入れられます。 VCのQoSを変更する複数のメッセージがインターバル中に到着した場合、冗長なメッセージが破棄される可能性があります。時間t + Tで、QoSの残りの変更があれば実行できます。このタイマーアプローチは、より一般的にはどのネットワーク構造にも適用され、RSVPに組み込む価値があるかもしれません。
The sequence of events for a single VC would be
単一のVCのイベントのシーケンスは次のようになります
- Wait if timer is active - Establish VC with new QoS - Remap data traffic to new VC - Tear down old VC - Activate timer
- タイマーがアクティブな場合は待機-新しいQoSでVCを確立-データトラフィックを新しいVCに再マップ-古いVCを破棄-タイマーをアクティブ化
There is an interesting interaction between heterogeneous reservations and dynamic QoS. In the case where a RESV message is received from a new next-hop and the requested resources are larger than any existing reservation, both dynamic QoS and heterogeneity need to be addressed. A key issue is whether to first add the new next-hop or to change to the new QoS. This is a fairly straight forward special case. Since the older, smaller reservation does not support the new next-hop, the dynamic QoS process should be initiated first. Since the new QoS is only needed by the new next-hop, it should be the first end-point of the new VC. This way signalling is minimized when the setup to the new next-hop fails.
異種混合予約と動的QoSの間には興味深い相互作用があります。 RESVメッセージが新しいネクストホップから受信され、要求されたリソースが既存の予約よりも大きい場合、動的QoSと異質性の両方に対処する必要があります。重要な問題は、最初に新しいネクストホップを追加するか、新しいQoSに変更するかです。これはかなり単純な特殊なケースです。古い、小さい予約は新しいネクストホップをサポートしないため、動的QoSプロセスを最初に開始する必要があります。新しいQoSは新しいネクストホップでのみ必要になるため、新しいVCの最初のエンドポイントにする必要があります。このようにして、新しいネクストホップへのセットアップが失敗した場合のシグナリングが最小限に抑えられます。
Short-cuts [4] allow ATM attached routers and hosts to directly establish point-to-point VCs across LIS boundaries, i.e., the VC end-points are on different IP subnets. The ability for short-cuts and RSVP to interoperate has been raised as a general question. An area of concern is the ability to handle asymmetric short-cuts. Specifically how RSVP can handle the case where a downstream short-cut may not have a matching upstream short-cut. In this case, PATH and RESV messages following different paths.
ショートカット[4]を使用すると、ATM接続のルーターとホストがLIS境界を越えてポイントツーポイントVCを直接確立できます。つまり、VCエンドポイントは異なるIPサブネット上にあります。ショートカットとRSVPが相互運用する機能は、一般的な質問として提起されています。関心のある領域は、非対称ショートカットを処理する機能です。具体的には、ダウンストリームショートカットに対応するアップストリームショートカットがない場合のRSVPの処理方法。この場合、異なるパスをたどるPATHメッセージとRESVメッセージ。
Examination of RSVP shows that the protocol already includes mechanisms that will support short-cuts. The mechanism is the same one used to support RESV messages arriving at the wrong router and the wrong interface. The key aspect of this mechanism is RSVP only processing messages that arrive at the proper interface and RSVP forwarding of messages that arrive on the wrong interface. The proper interface is indicated in the NHOP object of the message. So, existing RSVP mechanisms will support asymmetric short-cuts. The short-cut model of VC establishment still poses several issues when running with RSVP. The major issues are dealing with established best-effort short-cuts, when to establish short-cuts, and QoS only short-cuts. These issues will need to be addressed by RSVP implementations.
RSVPを調べると、プロトコルにはショートカットをサポートするメカニズムがすでに含まれていることがわかります。このメカニズムは、不適切なルーターと不適切なインターフェースに到着するRESVメッセージをサポートするために使用されるメカニズムと同じです。このメカニズムの重要な側面は、適切なインターフェイスに到着したメッセージのRSVPのみの処理と、間違ったインターフェイスに到着したメッセージのRSVP転送です。適切なインターフェイスは、メッセージのNHOPオブジェクトに示されています。そのため、既存のRSVPメカニズムは非対称ショートカットをサポートします。 RSVPで実行する場合、VC確立のショートカットモデルはまだいくつかの問題を引き起こします。主な問題は、確立されたベストエフォートのショートカット、ショートカットを確立するタイミング、およびQoSのみのショートカットを処理することです。これらの問題は、RSVP実装によって対処する必要があります。
The key issue to be addressed by any RSVP over ATM solution is when to establish a short-cut for a QoS data flow. The default behavior is to simply follow best-effort traffic. When a short-cut has been established for best-effort traffic to a destination or next-hop, that same end-point should be used when setting up RSVP triggered VCs for QoS traffic to the same destination or next-hop. This will happen naturally when PATH messages are forwarded over the best-effort short-cut. Note that in this approach when best-effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established. More study is expected in this area.
ATMソリューションを介したRSVPで対処する重要な問題は、QoSデータフローのショートカットをいつ確立するかです。デフォルトの動作では、単にベストエフォートのトラフィックを追跡します。宛先またはネクストホップへのベストエフォートトラフィックのショートカットが確立されている場合、同じ宛先またはネクストホップへのQoSトラフィックに対してRSVPトリガーVCを設定するときは、その同じエンドポイントを使用する必要があります。これは、PATHメッセージがベストエフォートのショートカットを介して転送されるときに自然に発生します。この方法では、ベストエフォートのショートカットが確立されない場合、RSVPによってトリガーされるQoSショートカットも確立されないことに注意してください。この分野でのさらなる研究が期待されています。
RSVP can identify from either explicit messages or timeouts when a data VC is no longer needed. Therefore, data VCs set up to support RSVP controlled flows should only be released at the direction of RSVP. VCs must not be timed out due to inactivity by either the VC initiator or the VC receiver. This conflicts with VCs timing out as described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755 recommends tearing down a VC that is inactive for a certain length of time. Twenty minutes is recommended. This timeout is typically implemented at both the VC initiator and the VC receiver. Although, section 3.1 of the update to RFC 1755 [11] states that inactivity timers must not be used at the VC receiver.
RSVPは、データVCが不要になったときに、明示的なメッセージまたはタイムアウトから識別できます。したがって、RSVP制御フローをサポートするように設定されたデータVCは、RSVPの指示でのみ解放する必要があります。 VCは、VCイニシエーターまたはVCレシーバーのいずれかによる非アクティブのためにタイムアウトしてはなりません。これは、VC TeardownのRFC 1755 [11]のセクション3.4で説明されているように、VCのタイムアウトと競合します。 RFC 1755では、一定期間非アクティブなVCを破棄することを推奨しています。 20分をお勧めします。このタイムアウトは通常、VCイニシエーターとVCレシーバーの両方で実装されます。ただし、RFC 1755 [11]の更新のセクション3.1には、非アクティブタイマーをVCレシーバーで使用してはならないことが記載されています。
When this timeout occurs for an RSVP initiated VC, a valid VC with QoS will be torn down unexpectedly. While this behavior is acceptable for best-effort traffic, it is important that RSVP controlled VCs not be torn down. If there is no choice about the VC being torn down, the RSVP daemon must be notified, so a reservation failure message can be sent.
RSVPによって開始されたVCに対してこのタイムアウトが発生すると、QoSを備えた有効なVCが予期せず破棄されます。この動作はベストエフォートトラフィックでは許容されますが、RSVPで制御されるVCが破棄されないことが重要です。 VCが破棄されるという選択肢がない場合は、RSVPデーモンに通知する必要があるため、予約失敗メッセージを送信できます。
For VCs initiated at the request of RSVP, the configurable inactivity timer mentioned in [11] must be set to "infinite". Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be relayed internally at the originator. Setting the inactivity timer at the VC receiver is more difficult, and would require some mechanism to signal that an incoming VC was RSVP initiated. To avoid this complexity and to conform to [11] implementations must not use an inactivity timer to clear received connections.
RSVPの要求で開始されたVCの場合、[11]で説明されている設定可能な非アクティブタイマーを「無限」に設定する必要があります。 VCイニシエーターで非アクティブタイマーの値を設定しても問題は発生しません。これは、適切な値が発信元で内部的に中継されるためです。 VCレシーバーで非アクティブタイマーを設定することはより困難であり、着信VCがRSVPで開始されたことを通知する何らかのメカニズムが必要になります。この複雑さを回避し、[11]に準拠するには、受信した接続をクリアするために非アクティブタイマーを使用しないでください。
One last important issue is providing a data path for the RSVP messages themselves. There are two main types of messages in RSVP, PATH and RESV. PATH messages are sent to unicast or multicast addresses, while RESV messages are sent only to unicast addresses. Other RSVP messages are handled similar to either PATH or RESV, although this might be more complicated for RERR messages. So ATM VCs used for RSVP signalling messages need to provide both unicast and multicast functionality. There are several different approaches for how to assign VCs to use for RSVP signalling messages.
最後の重要な問題の1つは、RSVPメッセージ自体にデータパスを提供することです。 RSVPには、PATHとRESVの2つの主要なタイプのメッセージがあります。 PATHメッセージはユニキャストまたはマルチキャストアドレスに送信されますが、RESVメッセージはユニキャストアドレスにのみ送信されます。他のRSVPメッセージは、PATHまたはRESVと同様に処理されますが、これはRERRメッセージの場合はより複雑になる可能性があります。したがって、RSVPシグナリングメッセージに使用されるATM VCは、ユニキャストとマルチキャストの両方の機能を提供する必要があります。 RSVPシグナリングメッセージに使用するVCを割り当てる方法には、いくつかの異なるアプローチがあります。
The main approaches are:
主なアプローチは次のとおりです。
- use same VC as data - single VC per session - single point-to-multipoint VC multiplexed among sessions - multiple point-to-point VCs multiplexed among sessions
- 同じVCをデータとして使用-セッションごとに単一のVC-セッション間で多重化された単一のポイントツーマルチポイントVC-セッション間で多重化された複数のポイントツーポイントVC
There are several different issues that affect the choice of how to assign VCs for RSVP signalling. One issue is the number of additional VCs needed for RSVP signalling. Related to this issue is the degree of multiplexing on the RSVP VCs. In general more multiplexing means fewer VCs. An additional issue is the latency in dynamically setting up new RSVP signalling VCs. A final issue is complexity of implementation. The remainder of this section discusses the issues and tradeoffs among these different approaches and suggests guidelines for when to use which alternative.
RSVPシグナリングにVCを割り当てる方法の選択に影響を与えるいくつかの異なる問題があります。 1つの問題は、RSVPシグナリングに必要な追加のVCの数です。この問題に関連するのは、RSVP VCでの多重化の程度です。一般に、多重化が多いほど、VCが少なくなります。追加の問題は、新しいRSVPシグナリングVCを動的にセットアップする際の遅延です。最後の問題は、実装の複雑さです。このセクションの残りの部分では、これらの異なるアプローチ間の問題とトレードオフについて説明し、どの代替手段をいつ使用するかについてのガイドラインを提案します。
In this scheme RSVP signalling messages are sent on the same VCs as is the data traffic. The main advantage of this scheme is that no additional VCs are needed beyond what is needed for the data traffic. An additional advantage is that there is no ATM signalling latency for PATH messages (which follow the same routing as the data messages). However there can be a major problem when data traffic on a VC is nonconforming. With nonconforming traffic, RSVP signalling messages may be dropped. While RSVP is resilient to a moderate level of dropped messages, excessive drops would lead to repeated tearing down and re-establishing of QoS VCs, a very undesirable behavior for ATM. Due to these problems, this may not be a good choice for providing RSVP signalling messages, even though the number of VCs needed for this scheme is minimized. One variation of this scheme is to use the best effort data path for signalling traffic. In this scheme, there is no issue with nonconforming traffic, but there is an issue with congestion in the ATM network. RSVP provides some resiliency to message loss due to congestion, but RSVP control messages should be offered a preferred class of service. A related variation of this scheme that is hopeful but requires further study is to have a packet scheduling algorithm (before entering the ATM network) that gives priority to the RSVP signalling traffic. This can be difficult to do at the IP layer.
この方式では、RSVPシグナリングメッセージは、データトラフィックと同じVCで送信されます。この方式の主な利点は、データトラフィックに必要なもの以外に追加のVCが必要ないことです。追加の利点は、PATHデータ（データメッセージと同じルーティングに従う）のATMシグナリングレイテンシがないことです。ただし、VC上のデータトラフィックが不適合である場合、大きな問題が発生する可能性があります。非準拠トラフィックでは、RSVPシグナリングメッセージがドロップされる場合があります。 RSVPは中程度のレベルのドロップメッセージに対して回復力がありますが、過剰なドロップは、ATMにとって非常に望ましくない動作であるQoS VCの破棄と再確立を繰り返すことになります。これらの問題のため、この方式に必要なVCの数は最小限に抑えられていますが、これはRSVPシグナリングメッセージを提供するための適切な選択ではない場合があります。この方式のバリエーションの1つは、トラフィックのシグナリングにベストエフォートデータパスを使用することです。この方式では、非準拠のトラフィックには問題はありませんが、ATMネットワークの輻輳には問題があります。 RSVPは、輻輳によるメッセージ損失にある程度の回復力を提供しますが、RSVP制御メッセージは、優先クラスのサービスを提供する必要があります。この方式の関連するバリエーションとして、希望はあるもののさらなる調査が必要なものとして、RSVPシグナリングトラフィックを優先するパケットスケジューリングアルゴリズム（ATMネットワークに入る前）があります。これはIP層で行うのが難しい場合があります。
In this scheme, there is a parallel RSVP signalling VC for each RSVP reservation. This scheme results in twice the number of VCs, but means that RSVP signalling messages have the advantage of a separate VC. This separate VC means that RSVP signalling messages have their own traffic contract and compliant signalling messages are not subject to dropping due to other noncompliant traffic (such as can happen with the scheme in section 4.3.1). The advantage of this scheme is its simplicity - whenever a data VC is created, a separate RSVP signalling VC is created. The disadvantage of the extra VC is that extra ATM signalling needs to be done. Additionally, this scheme requires twice the minimum number of VCs and also additional latency, but is quite simple.
この方式では、RSVP予約ごとにパラレルRSVPシグナリングVCがあります。この方式では、VCの数が2倍になりますが、RSVPシグナリングメッセージには、独立したVCの利点があります。この個別のVCは、RSVPシグナリングメッセージに独自のトラフィックコントラクトがあり、準拠するシグナリングメッセージが他の非準拠トラフィック（セクション4.3.1のスキームで発生する可能性があるなど）が原因でドロップされないことを意味します。この方式の利点は、その単純さです。データVCが作成されるたびに、個別のRSVPシグナリングVCが作成されます。追加のVCの欠点は、追加のATMシグナリングを実行する必要があることです。さらに、このスキームでは、VCの最小数の2倍と追加のレイテンシが必要になりますが、非常に簡単です。
In this scheme, there is a single point-to-multipoint RSVP signalling VC for each unique ingress router and unique set of egress routers. This scheme allows multiplexing of RSVP signalling traffic that shares the same ingress router and the same egress routers. This can save on the number of VCs, by multiplexing, but there are problems when the destinations of the multiplexed point-to-multipoint VCs are changing. Several alternatives exist in these cases, that have applicability in different situations. First, when the egress routers change, the ingress router can check if it already has a point-to-multipoint RSVP signalling VC for the new list of egress routers. If the RSVP signalling VC already exists, then the RSVP signalling traffic can be switched to this existing VC. If no such VC exists, one approach would be to create a new VC with the new list of egress routers. Other approaches include modifying the existing VC to add an egress router or using a separate new VC for the new egress routers. When a destination drops out of a group, an alternative would be to keep sending to the existing VC even though some traffic is wasted. The number of VCs used in this scheme is a function of traffic patterns across the ATM network, but is always less than the number used with the Single RSVP VC per data VC. In addition, existing best effort data VCs could be used for RSVP signalling. Reusing best effort VCs saves on the number of VCs at the cost of higher probability of RSVP signalling packet loss. One possible place where this scheme will work well is in the core of the network where there is the most opportunity to take advantage of the savings due to multiplexing. The exact savings depend on the patterns of traffic and the topology of the ATM network.
このスキームでは、各一意の入力ルーターと一意の一連の出力ルーターに対して、単一のポイントツーマルチポイントRSVPシグナリングVCがあります。このスキームにより、同じ入力ルータと同じ出力ルータを共有するRSVPシグナリングトラフィックの多重化が可能になります。これにより、多重化によってVCの数を節約できますが、多重化されたポイントツーマルチポイントVCの宛先が変更されると問題が発生します。これらのケースにはいくつかの選択肢があり、さまざまな状況に適用できます。まず、出力ルーターが変更されると、入力ルーターは、出力ルーターの新しいリスト用のポイントツーマルチポイントRSVPシグナリングVCがすでにあるかどうかを確認できます。 RSVPシグナリングVCがすでに存在する場合、RSVPシグナリングトラフィックをこの既存のVCに切り替えることができます。そのようなVCが存在しない場合、1つのアプローチは、出力ルーターの新しいリストを使用して新しいVCを作成することです。その他のアプローチには、既存のVCを変更して出力ルーターを追加することや、新しい出力ルーターに別の新しいVCを使用することが含まれます。宛先がグループから脱落した場合、一部のトラフィックが浪費されていても、代替策は既存のVCに送信し続けることです。この方式で使用されるVCの数は、ATMネットワーク全体のトラフィックパターンの関数ですが、データVCごとに単一のRSVP VCで使用される数より常に少ないです。さらに、既存のベストエフォートデータVCをRSVPシグナリングに使用できます。ベストエフォートVCを再利用すると、RSVPシグナリングパケット損失の可能性が高くなりますが、VCの数を節約できます。このスキームがうまく機能する可能性のある場所の1つは、ネットワークのコアにあります。このコアでは、多重化による節約を活用する機会が最も多くなります。正確な節約は、トラフィックのパターンとATMネットワークのトポロジーに依存します。
In this scheme, multiple point-to-point RSVP signalling VCs are used for a single point-to-multipoint data VC. This scheme allows multiplexing of RSVP signalling traffic but requires the same traffic to be sent on each of several VCs. This scheme is quite flexible and allows a large amount of multiplexing.
この方式では、複数のポイントツーポイントRSVPシグナリングVCが単一のポイントツーマルチポイントデータVCに使用されます。この方式では、RSVPシグナリングトラフィックを多重化できますが、複数のVCのそれぞれで同じトラフィックを送信する必要があります。このスキームは非常に柔軟で、大量の多重化を可能にします。
Since point-to-point VCs can set up a reverse channel at the same time as setting up the forward channel, this scheme could save substantially on signalling cost. In addition, signalling traffic could share existing best effort VCs. Sharing existing best effort VCs reduces the total number of VCs needed, but might cause signalling traffic drops if there is congestion in the ATM network. This point-to-point scheme would work well in the core of the network where there is much opportunity for multiplexing. Also in the core of the network, RSVP VCs can stay permanently established either as Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual Circuits (SVCs). The number of VCs in this scheme will depend on traffic patterns, but in the core of a network would be approximately n(n-1)/2 where n is the number of IP nodes in the network. In the core of the network, this will typically be small compared to the total number of VCs.
ポイントツーポイントVCは、フォワードチャネルのセットアップと同時にリバースチャネルをセットアップできるため、この方式では、シグナリングコストを大幅に節約できます。さらに、シグナリングトラフィックは既存のベストエフォートVCを共有できます。既存のベストエフォートVCを共有すると、必要なVCの総数が減りますが、ATMネットワークに輻輳があると、シグナリングトラフィックがドロップする可能性があります。このポイントツーポイントスキームは、多重化の機会が多いネットワークのコアでうまく機能します。また、ネットワークのコアでは、RSVP VCは永続的仮想回線（PVC）または長寿命のスイッチド仮想回線（SVC）のいずれかとして永続的に確立された状態を維持できます。このスキームのVCの数はトラフィックパターンによって異なりますが、ネットワークのコアでは約n（n-1）/ 2になります。ここで、nはネットワーク内のIPノードの数です。ネットワークのコアでは、これは通常、VCの総数と比較して小さいです。
There is an issue of what QoS, if any, to assign to the RSVP signalling VCs. For other RSVP VC schemes, a QoS (possibly best effort) will be needed. What QoS to use partially depends on the expected level of multiplexing that is being done on the VCs, and the expected reliability of best effort VCs. Since RSVP signalling is infrequent (typically every 30 seconds), only a relatively small QoS should be needed. This is important since using a larger QoS risks the VC setup being rejected for lack of resources. Falling back to best effort when a QoS call is rejected is possible, but if the ATM net is congested, there will likely be problems with RSVP packet loss on the best effort VC also. Additional experimentation is needed in this area.
RSVPシグナリングVCに割り当てるQoSがある場合、その問題があります。他のRSVP VCスキームの場合、QoS（おそらくベストエフォート）が必要になります。どのQoSを使用するかは、VCで行われている多重化の予想されるレベル、およびベストエフォートVCの予想される信頼性に部分的に依存します。 RSVPシグナリングは頻繁ではないため（通常30秒ごと）、必要なのは比較的小さなQoSだけです。より大きなQoSを使用すると、VCセットアップがリソース不足のために拒否されるリスクがあるため、これは重要です。 QoSコールが拒否されたときにベストエフォートにフォールバックすることは可能ですが、ATMネットが輻輳している場合、ベストエフォートVCでのRSVPパケット損失の問題も発生する可能性があります。この領域では、追加の実験が必要です。
Since RSVP is a signalling protocol used to control flows of IP data packets, encapsulation for both RSVP packets and associated IP data packets must be defined. The methods for transmitting IP packets over ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based on the encapsulations defined in RFC1483 [19]. RFC1483 specifies two encapsulations, LLC Encapsulation and VC-based multiplexing. The former allows multiple protocols to be encapsulated over the same VC and the latter requires different VCs for different protocols.
RSVPはIPデータパケットのフローを制御するために使用されるシグナリングプロトコルであるため、RSVPパケットと関連するIPデータパケットの両方のカプセル化を定義する必要があります。 ATM（Classical IP over ATM [10]、LANE [17]、およびMPOA [18]）を介してIPパケットを送信する方法はすべて、RFC1483 [19]で定義されているカプセル化に基づいています。 RFC1483は、LLCカプセル化とVCベースの多重化という2つのカプセル化を指定しています。前者は複数のプロトコルを同じVC上でカプセル化することを可能にし、後者は異なるプロトコルに対して異なるVCを必要とします。
For the purposes of RSVP over ATM, any encapsulation can be used as long as the VCs are managed in accordance to the methods outlined in Section 4. Obviously, running multiple protocol data streams over the same VC with LLC encapsulation can cause the same problems as running multiple flows over the same VC.
ATM上のRSVPの目的では、VCがセクション4で概説されている方法に従って管理されている限り、任意のカプセル化を使用できます。明らかに、LLCカプセル化で同じVC上で複数のプロトコルデータストリームを実行すると、同じ問題が発生する可能性があります。同じVC上で複数のフローを実行する。
While none of the transmission methods directly address the issue of QoS, RFC1755 [11] does suggest some common values for VC setup for best-effort traffic. [14] discusses the relationship of the RFC1755 setup parameters and those needed to support IntServ flows in greater detail.
QoSの問題に直接対処する送信方法はありませんが、RFC1755 [11]は、ベストエフォートトラフィックのVCセットアップにいくつかの一般的な値を提案しています。 [14]は、RFC1755セットアップパラメータとIntServフローをサポートするために必要なパラメータの関係をより詳細に説明しています。
The same considerations stated in [1] and [11] apply to this document. There are no additional security issues raised in this document.
[1]と[11]で述べたのと同じ考慮事項がこのドキュメントに適用されます。このドキュメントで発生した追加のセキュリティ問題はありません。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2209, September 1997.
[1] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2209、1997年9月。
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Realtime Services in an IP-ATM Network Architecture", RFC 1821, August 1995.
[2] Borden、M.、Crawley、E.、Davie、B。、およびS. Batsell、「IP-ATMネットワークアーキテクチャにおけるリアルタイムサービスの統合」、RFC 1821、1995年8月。
[3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", RFC 1932, April 1996.
[3] Cole、R.、Shur、D。、およびC. Villamizar、「IP over ATM：A Framework Document」、RFC 1932、1996年4月。
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[4] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[5] アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1996年11月。
[6] Shenker, S., and C. Partridge, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[6] Shenker、S。、およびC. Partridge、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[7] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[7] Wroclawski、J。、「Controlled-Load Network Element Serviceの仕様」、RFC 2211、1997年9月。
[8] ATM Forum. ATM User-Network Interface Specification Version 3.0. Prentice Hall, September 1993.
[8] ATMフォーラム。 ATM User-Network Interface Specification Version 3.0。プレンティスホール、1993年9月。
[9] ATM Forum. ATM User Network Interface (UNI) Specification Version 3.1. Prentice Hall, June 1995.
[9] ATMフォーラム。 ATMユーザーネットワークインターフェイス（UNI）仕様バージョン3.1。プレンティスホール、1995年6月。
[10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[10] Laubach、M。、「Classical IP and ARP over ATM」、RFC 2225、1998年4月。
[11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[11] Perez、M.、Mankin、A.、Hoffman、E.、Grossman、G。、およびA. Malis、「ATM Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[12] Herzog, S., "RSVP Extensions for Policy Control", Work in Progress.
[12] Herzog、S.、「ポリシー制御のためのRSVP拡張機能」、作業中。
[13] Herzog, S., "Local Policy Modules (LPM): Policy Control for RSVP", Work in Progress.
[13] Herzog、S。、「Local Policy Modules（LPM）：Policy Control for RSVP」、Work in Progress。
[14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load and Guaranteed Service with ATM", RFC 2381, August 1998.
[14] Borden、M。、およびM. Garrett、「ATMによる制御負荷および保証サービスの相互運用」、RFC 2381、1998年8月。
[15] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[15] Berger、L。、「RSVP over ATMの実装要件」、RFC 2380、1998年8月。
[16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379, August 1998.
[16] Berger、L。、「RSVP over ATM実装ガイドライン」、RFC 2379、1998年8月。
[17] ATM Forum Technical Committee. LAN Emulation over ATM, Version 1.0 Specification, af-lane-0021.000, January 1995.
[17] ATMフォーラム技術委員会。 LAN Emulation over ATM、バージョン1.0仕様、af-lane-0021.000、1995年1月。
[18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95- 0824r9, September 1996.
[18] ATMフォーラム技術委員会。 MPOAのベースラインテキスト、af-95-0824r9、1996年9月。
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[19] Heinanen、J。、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2 - LUNI Specification, December 1996.
[20] ATMフォーラム技術委員会。 LANエミュレーションover ATMバージョン2-LUNI仕様、1996年12月。
[21] ATM Forum Technical Committee. Traffic Management Specification v4.0, af-tm-0056.000, April 1996.
[21] ATMフォーラム技術委員会。トラフィック管理仕様v4.0、af-tm-0056.000、1996年4月。
[22] Callon, R., et al., "A Framework for Multiprotocol Label Switching, Work in Progress.
[22] Callon、R.、et al。、 "A Framework for Multiprotocol Label Switching、Work in Progress。
[23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[23] Rajagopalan、B.、Nair、R.、Sandick、H。、およびE. Crawley、「インターネットにおけるQoSベースのルーティングのフレームワーク」、RFC 2386、1998年8月。
[24] ITU-T. Digital Subscriber Signaling System No. 2-Connection modification: Peak cell rate modification by the connection owner, ITU-T Recommendation Q.2963.1, July 1996.
[24] ITU-T。 Digital Subscriber Signaling System No. 2-Connectionの変更：接続の所有者によるピークセルレートの変更、ITU-T勧告Q.2963.1、1996年7月。
[25] ITU-T. Digital Subscriber Signaling System No. 2-Connection characteristics negotiation during call/connection establishment phase, ITU-T Recommendation Q.2962, July 1996.
[25] ITU-T。 Digital Subscriber Signaling System No.2-コール/接続確立フェーズ中の接続特性ネゴシエーション、ITU-T勧告Q.2962、1996年7月。
[26] ATM Forum Technical Committee. Private Network-Network Interface Specification v1.0 (PNNI), March 1996.
[26] ATMフォーラム技術委員会。 Private Network-Network Interface Specification v1.0（PNNI）、1996年3月。
Eric S. Crawley Argon Networks 25 Porter Road Littleton, Ma 01460
Eric S. Crawley Argon Networks 25 Porter Road Littleton、MA 01460
Phone: +1 978 486-0665
EMail: esc@argon.com
Lou Berger FORE Systems 6905 Rockledge Drive Suite 800 Bethesda, MD 20817
Lou Berger FORE Systems 6905 Rockledge Drive Suite 800ベセスダ、MD 20817
Phone: +1 301 571-2534
EMail: lberger@fore.com
Steven Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Steven Berson USC Information Sciences Institute 4676 Admiralty Wayマリナデルレイ、カリフォルニア90292
Phone: +1 310 822-1511
EMail: berson@isi.edu
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111
Fred Baker Cisco Systems 519 Lado Driveサンタバーバラ、カリフォルニア93111
Phone: +1 805 681-0115 EMail: fred@cisco.com Marty Borden Bay Networks 125 Nagog Park Acton, MA 01720
電話：+1 605 81-0G5メール：Fredisco.co Marty Borden Bay Networks 125 Nagg Park Octen、Ma 017
Phone: +1 978 266-1011
EMail: mborden@baynetworks.com
John J. Krawczyk ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886
John J. Krawczyk ArrowPoint Communications 235 Littleton Road Westford、Massachusetts 01886
Phone: +1 978 692-5875
EMail: jj@arrowpoint.com
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。