RFC1821 日本語訳
1821 Integration of Real-time Services in an IP-ATM NetworkArchitecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August 1995. (Format: TXT=64466 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Borden
Request for Comments: 1821 E. Crawley
Category: Informational Bay Networks
B. Davie
Bellcore
S. Batsell
NRL
August 1995
コメントを求めるワーキンググループM.ボーデンの要求をネットワークでつないでください: 1821年のE.クローリーカテゴリ: 情報のベイネットワークスのB.デイビーBellcore S.Batsell NRL1995年8月
Integration of Real-time Services in an IP-ATM Network Architecture
IP-気圧ネットワークアーキテクチャにおけるリアルタイムでサービスの統合
Status of the Memo
メモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet. Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services.
IETFは現在、インターネットでリアルタイムのサービスをサポートするように設計されている統合サービスモデルを開発しています。 同時に、ATM Forumは同様にリアルタイムのネットワークサポートを提供するAsynchronous Transfer Modeネットワークを開発しています。 リンクレイヤプロトコルとしてのインターネットでのATMの使用は既に起こっています、そして、IETFとATM Forumの両方がATMの上にIPのための仕様を作り出しています。 この紙の目的はどんな問題が、リアルタイムのネットワークサービスを望んでいるエンドユーザを支持して2つの間の継ぎ目のないインタフェースを作成するためにIPの統合サービス環境をATMサービス環境に連結する際に扱われる必要があるかに関する明確な声明を提供することです。
Table of Contents
目次
1.0 Introduction 2 2.0 Problem Space Overview 3 2.1 Initial Assumptions 3 2.2 Topologies Under Consideration 4 2.3 Providing QoS in IP over ATM - a walk-though 5 3.0 Service Model Issues 6 3.1 Traffic Characterization 7 3.2 QoS Characterization 8 4.0 Resource Reservation Styles 10 4.1 RSVP 10 4.2 ST-II 13 4.3 Mapping IP flows to ATM Connections 15 5.0 End System Issues 16 6.0 Routing Issues 16
1.0序論2 2.0Problem Space Overview3 2.1Initial Assumptions3 2.2Topologies Under Consideration、4、2.3Providing QoS、ATMの上のIP、--もっとも、散歩5 3.0Service Model Issues6 3.1Traffic Characterization7 3.2QoS Characterization8 4.0Resource予約様式10 4.1RSVP10標準時4.2II13 4.3Mapping IPがATMコネクションズ15 5.0End System Issues16 6.0ルート設定Issues16に注ぐ
Borden, et al Informational [Page 1] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[1ページ]RFC1821レアル-時間Service
6.1 Multicast routing 17 6.2 QoS Routing 17 6.3 Mobile Routing 18 7.0 Security Issues 19 8.0 Future Directions 20 9.0 References 22 10.0 Authors' Addresses 24
6.1 ルーティング17 6.2マルチキャストQoSルート設定17 6.3のモバイルルート設定18 7.0Security Issues19 8.0Future Directions20 9.0References22 10.0のAuthorsのAddresses24
1.0 Introduction
1.0 序論
The traditional network service on the Internet is best-effort datagram transmission. In this service, packets from a source are sent to a destination, with no guarantee of delivery. For those applications that require a guarantee of delivery, the TCP protocol will trade packet delay for correct reception by retransmitting those packets that fail to reach the destination. For traditional computer-communication applications such as FTP and Telnet in which correct delivery is more important than timeliness, this service is satisfactory. However, a new class of application which uses multiple media (voice, video, and computer data) has begun to appear on the Internet. Examples of this class of application are video teleconferencing, video-on-demand, and distributed simulation. While these applications can operate to some extent using best-effort delivery, trading packet delay for correct reception is not an acceptable trade-off. Operating in the traditional mode for these applications results in reduced quality of the received information and, potentially, inefficient use of bandwidth. To remedy this problem the IETF is developing a real-time service environment in which multiple classes of service are offered [6]. This environment will greatly extend the existing best-effort service model to meet the needs of multimedia applications with real-time constraints.
インターネットにおける伝統的ネットワークサービスはベストエフォート型データグラムトランスミッションです。 このサービスでは、受渡保証なしでソースからのパケットを目的地に送ります。 受渡保証を必要とするそれらのアプリケーションのために、TCPプロトコルは、目的地に達しないそれらのパケットを再送することによって、正しいレセプションのためのパケット遅れを取り引きするでしょう。 正しい配送がタイムリーより重要であるFTPやTelnetなどの伝統的なコンピュータコミュニケーションアプリケーションにおいて、このサービスは満足できます。 しかしながら、マルチメディア(声、ビデオ、およびコンピュータのデータ)を使用する新しいクラスの適用はインターネットに現れ始めました。 このクラスの適用に関する例は、ビデオ遠隔会議と、ビデオ・オン・デマンドと、分配されたシミュレーションです。 これらのアプリケーションはベストエフォート型配送をある程度使用することで作動できますが、正しいレセプションのための取り引きパケット遅れは許容できるトレードオフではありません。 これらのアプリケーションのための伝統的なモードで作動するのは受信された情報の減少している品質と帯域幅の潜在的に効率の悪い使用をもたらします。 この問題を改善するために、IETFはどの複数のクラスのサービスに[6]を提供するかでリアルタイムのサービス環境を開発しています。 この環境は、リアルタイムの規制でマルチメディア応用の需要を満たすために既存のベストエフォート型サービスモデルを大いに広げるでしょう。
At the same time that this effort is underway in the IETF, Asynchronous Transfer Mode (ATM) is being developed, initially as a replacement for the current telephone network protocols, but more recently as a link-layer protocol for computer communications. As it was developed from the beginning with telephone voice applications in mind, a real-time service environment is an integral part of the protocol. With the approval of UNI 3.1 by the ATM Forum, the ATM standards now have several categories of service. Given the wide acceptance of ATM by the long-line carriers, the use of ATM in the Internet is, if not guaranteed, highly likely. The question now becomes, how can we successfully interface between the real-time services offered by ATM and the new,integrated service environment soon to be available in the IP protocol suite. The current IP over ATM standards assume no real-time IP protocols. It is the purpose of this RFC to clearly delineate what the issues are in integrating real-time services in an IP-over-ATM network [10,15,19,20,21].
しかし、この取り組みがIETFで進行中であることの同時に、Asynchronous Transfer Mode(ATM)は初めは現在の電話ネットワーク・プロトコルのために交換として開発される最近、リンク層プロトコルとしてコンピュータコミュニケーションのための以上です。 それが念頭で電話音声アプリケーションで始めから開発されたとき、リアルタイムのサービス環境はプロトコルの不可欠の部分です。 ATM ForumによるUNI3.1の承認によって、ATM規格に、現在、いくつかのサービスのカテゴリがあります。 はえなわキャリヤーによるATMの広い承認を考えて、保証されないなら、インターネットでのATMの使用は非常にありそうです。 現在質問はなって、私たちは、すぐ、IPプロトコル群で利用可能になるようにATMによって提供された、リアルタイムのサービスと、新しくて、統合しているサービス環境の間でどうしたら首尾よく連結できますか? ATM規格の上の現在のIPはどんなリアルタイムのIPプロトコルも仮定しません。 問題がIP過剰ATMネットワーク[10、15、19、20、21]にリアルタイムのサービスを統合することにおいてものであることを明確に図で表わすのは、このRFCの目的です。
Borden, et al Informational [Page 2] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[2ページ]RFC1821レアル-時間Service
In the IP-over-ATM environment, as in many others, multicast routing adds an additional set of challenges. While the major focus of this paper is quality of service (QoS) issues, it is unwise at best to ignore multicast when considering these issues, especially since so many of the applications that motivate the provision of real time QoS also require efficient multicast support. We will therefore try to keep considerations of multicast in the foreground in the following discussion.
IP過剰ATM環境で、多くの他のもののように、マルチキャストルーティングは追加挑戦を加えます。 この紙の主要な焦点はサービスの質(QoS)問題ですが、これらの問題を考えるとき、マルチキャストを無視するのはせいぜい賢明ではありません、また、特にリアルタイムのQoSの設備を動機づけるアプリケーションがあまりに多いのが効率的なマルチキャストサポートを必要とするので。 したがって、私たちは以下の議論におけるフォアグランドにおけるマルチキャストの問題を保とうとするでしょう。
One of the primary motivations for this document is a belief by the authors that ATM should, if possible, be used as more than a leased line replacement. That is to say, while it is possible for the Internet to be overlaid on constant bit rate (CBR), permanent virtual circuits (PVCs), thus reducing IP over ATM to a previously solved problem, we believe that this is unlikely to be the most efficient way to use ATM services as they are offered by carriers or as they appear in LANs. For example, a carrier offering a CBR service must assume that the peak bit rate can be used continuously with no degradation in quality and so resources must be allocated to the connection to provide that service, even if the peak rate is in fact rarely used. This is likely to make a CBR service more expensive that a variable bit rate service of the same peak capacity. Another way to view this is that the new IP service model will allow us to associate information about the bandwidth requirements of applications with individual flows; surely it is not wise to discard this information when we request a service from an ATM subnet.
このドキュメントに関するプライマリ動機の1つは作者によるできれば、ATMが専用線交換以上として使用されるべきであるという信念です。 その結果、すなわち、インターネットが固定ビットレート(CBR)でかぶせられるのが、可能である間の相手固定接続(PVCs)、私たちはこれがそれらがキャリヤーによって提供されるか、または彼らがLANに現れるようにATMサービスを利用する最も効率的な方法でありそうにないと信じて、ATMの上で以前に解決している問題にIPを減少させます。 例えば、CBRサービスを提供するキャリヤーは、退行なしで品質にピークビット伝送速度を絶え間なく使用できるのでそのサービスを提供するためにリソースを接続に割り当てなければならないと仮定しなければなりません、ピークレートがめったに事実上使用されないでも。 これはCBRサービスを同じピーク容量について、より高価に可変ビット伝送速度が修理するしそうです。 これを見る別の方法は新しいIPサービスモデルが私たちにアプリケーションの帯域幅要件の情報を個々の流れに関連づけさせるつもりであるということです。 確実に、私たちがいつATMサブネットからサービスを要求するかというこの情報を捨てるのは賢明ではありません。
While we believe that there is a range of capabilities in ATM networks that can be effectively used by a real-time Internet, we do not believe that just because ATM has a capability, the Internet must use it. Thus, our goal in this RFC is to begin to explore how an Internet with real time service capability might make most effective use of ATM networks. Since there are a number of problems to be resolved to achieve this effective use, our major goal at this point is to describe the scope of the problems that need to be addressed.
事実上、リアルタイムのインターネットで使用できるATMネットワークにはさまざまな能力があると信じている間、私たちは、ただATMに能力があるのでインターネットがそれを使用しなければならないと信じていません。 したがって、このRFCの私たちの目標はリアルタイムのサービス能力があるインターネットがどうATMの最も効果的な使用をネットワークにするかもしれないかを探検し始めることです。 この有効な使用を達成するために決議されるために多くの問題があるので、ここの私たちの主要な目標は扱われる必要がある問題の範囲について説明することです。
2.0 Problem Space Overview
2.0 問題スペース概要
In this section we aim to describe in high level terms the scope of the problem that will be explored in more detail in later sections.
このセクションでは、私たちは、高い平らな用語でさらに詳細に後のセクションで探られる問題の範囲について説明することを目指します。
2.1 Initial Assumptions
2.1 初期の仮定
We begin by assuming that an Integrated Services Internet, i.e., an Internet with a range of qualities of service to support both real- time and non-real-time applications, will eventually happen. A number of working groups are trying to make this happen, notably
Integrated Servicesインターネット(すなわち、さまざまな両方がリアルタイムと非リアルタイムのアプリケーションであるとサポートするサービスの品質があるインターネット)が結局起こると仮定することによって、私たちは始めます。 多くのワーキンググループがこれを著しく起こらせようとしています。
Borden, et al Informational [Page 3] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[3ページ]RFC1821レアル-時間Service
* the Integrated Services group (int-serv), which is working to define
a new IP service model, including a set of services suited to a
range of real-time applications;
* Integrated Servicesは新しいIPサービスモデルを定義するために働いている(int-serv)を分類します、さまざまなリアルタイムのアプリケーションに合う1セットのサービスを含んでいて。
* the Resource reservation Setup Protocol group (rsvp), which is
defining a resource reservation protocol [7] by which the
appropriate service for an application can be requested from the
network;
* Resource予約Setupプロトコルグループ(rsvp)(資源予約を定義している)はネットワークからアプリケーションのための適切なサービスを要求できる[7]について議定書の中で述べます。
* the Internet Streams Protocol V2 group (ST-II), which is updating
[27], a stream-oriented internet protocol that provides a range of
service qualities.
* インターネットStreamsプロトコルV2は(ST-II)を分類します。(それは、[27](さまざまなサービス品質を提供するストリーム指向のインターネットプロトコル)をアップデートしています)。
In addition, the IETF IP over ATM working group and the ATM Forum Multiprotocol over ATM group are working to define a model for protocols to make use of the ATM layer.
さらに、ATMワーキンググループの上のIETF IPとATMグループの上のATM Forum Multiprotocolは、プロトコルがATM層を利用するようにモデルを定義するために働いています。
Since these groups have not yet generated standards, we will need to do some amount of extrapolation to predict the problems that may arise for IP over ATM. We also assume that the standards being developed in the ATM Forum will largely determine the service model for ATM. Again, some extrapolation may be needed. Given these assumptions, this paper aims to explore ways in which a future Integrated Services Internet might make effective use of ATM as it seems likely to be deployed.
これらのグループがまだ規格を生成していないので、私たちは、IPのためにATMの上に起こるかもしれない問題を予測するためにいくらかの量の推定をする必要があるつもりです。 また、私たちは、ATM Forumで開発される規格がATMのためにサービスモデルを主に決定すると思います。 一方、何らかの推定が必要であるかもしれません。 これらの仮定を考えて、この紙は、配布されるのがありそうに思えるように将来のIntegrated ServicesインターネットがATMをうまく利用するかもしれない方法を探ることを目指します。
2.2 Topologies Under Consideration
2.2 考慮でのTopologies
Figure 1 shows a generic internetwork that includes ATM and non-ATM subnetworks. This paper aims to outline the problems that must be addressed to enable suitable quality of service to be provided end- to-end across such a network. The problem space, therefore, includes
図1はATMと非ATMサブネットワークを含んでいるジェネリックインターネットワークを示しています。 この紙は、そのようなネットワークの向こう側の終わりの終わりが適当なサービスの質に提供されるのを可能にするために扱わなければならない問題について概説することを目指します。 したがって、問題はインクルードを区切ります。
* communication across an 'ATM-only' network between two hosts
directly connected to the ATM network;
* 2人のホストの間の'ATM専用'ネットワークの向こう側のコミュニケーションは直接ATMネットワークに接続しました。
* communication between ATM-connected hosts which involves traversing
some non-ATM subnets;
* ATMによって接続されたホストのいくつかの非ATMサブネットを横断することを伴うコミュニケーション。
* communication between a host on a non-ATM subnet and a host directly
connected to ATM;
* 非ATMサブネットのホストとホストとのコミュニケーションは直接ATMに接続しました。
* communication between two hosts, neither of which has a direct ATM
connection, but which may make use of one or more ATM networks for
some part of the path.
* 2人のホストのコミュニケーション。(そのホストは、それのどちらもダイレクトATM接続がありませんが、経路の何らかの地域に1つ以上のATMネットワークを利用するかもしれません)。
Borden, et al Informational [Page 4] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[4ページ]RFC1821レアル-時間Service
[H]
| [H]
________|________________________ |
| | |
________|__ ______|___|____
| | | |
| ATM [R] [R] ATM |
| Cloud | | Cloud |___[H]
| | Non-ATM Internet | |
| | [R] |
|________[R] |_____________|
| | |
| | |
[H] |________________________________|
|
|
[H]
[H]| [H]________|________________________ | | | | ________|__ ______|___|____ | | | | | 気圧[R][R]気圧| | 雲| | 雲|___[H]| | 非気圧インターネット| | | | [R]| |________[R]|_____________| | | | | | | [H]|________________________________| | | [H]
[H] = Host
[R] = Router
Figure 1
[H] = ホスト[R]はルータ図1と等しいです。
In the last case, the entities connected to the ATM network are IP routers, and it is their job to manage the QoS provided by the ATM network(s) in such a way that the desired end-to-end QoS is provided to the hosts. While we wish to describe the problem space in a way that covers all of these scenarios, the last is perhaps the most general, so we will use it for most illustrative purposes. In particular, we are explicitly not interested in ways of providing QoS that are applicable only to a subset of these situations. We claim that addressing these four situations is sufficiently general to cover other situations such as those in which several ATM and non-ATM networks are traversed.
最後の場合では、ATMネットワークに関連づけられた実体はIPルータです、そして、ATMネットワークによって終わりから終わりへの必要なQoSをホストに提供するような方法で提供されたQoSを管理するのは、彼らの仕事です。 これらのシナリオのすべてをカバーする方法で問題スペースについて説明したいと思いますが、最終が恐らく最も一般的であるので、私たちはほとんどの説明に役立った目的にそれを使用するつもりです。 特に、私たちは明らかにこれらの状況の部分集合だけに適切なQoSを提供する方法に興味を持っていません。 私たちは、これらの4つの状況を扱うのがいくつかのATMと非ATMネットワークが横断されるそれらなどの他の状況をカバーできるくらい一般的であると主張します。
It is worth mentioning that the ATM networks in this case might be local or wide area, private or public. In some cases, this distinction may be significant, e.g., because there may be economic implications to a particular approach to providing QoS.
それは、この場合、ATMネットワークが地方の、または、広い領域であるかもしれないと言及する価値がある、個人的であるかまたは公共です。 いくつかの場合、この区別は重要であるかもしれません、例えば、QoSを提供することへの特定のアプローチへの経済含意があるかもしれないので。
2.3 Providing QoS in IP over ATM - a walk-through
ATMの上のIPにおける2.3提供QoS--立ち稽古
To motivate the following discussion, this section walks through an example of what might happen when an application with a certain set of QoS needs starts up. For this example, we will use the fourth case mentioned above, i.e., two hosts connected to non-ATM networks, making use of an ATM backbone.
以下の議論を動機づけるために、このセクションはあるQoSの必要性があるアプリケーションが始動すると何が起こるかもしれないかに関する例を通って歩きます。 この例のために、私たちは前記のように4番目のケースを使用するつもりです、すなわち、非ATMネットワークに接続された、2人のホスト、ATMバックボーンを利用して。
Borden, et al Informational [Page 5] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[5ページ]RFC1821レアル-時間Service
A generic discussion of this situation is made difficult by the fact that the reservation of resources in the Internet may be sender or receiver initiated, depending on the specifics of the setup protocol. We will attempt to gloss over this distinction for now, although we will return to it in Section 4. We will assume a unicast application and that the traffic characteristics and the QoS requirements (such as delay, loss, throughput) of the application are known to at least one host. That host launches a request for the desired QoS and a description of the expected traffic into the network; at some point this request hits a router at the edge of the ATM network. The router must examine the request and decide if it can use an existing connection over the ATM network to honor the request or whether it must establish a new connection. In the latter case, it must use the QoS and traffic characterizations to decide what sort of ATM connection to open and to describe the desired service to the ATM network. It must also decide where to open the connection to. Once the connection is opened, the request is forwarded across the ATM network to the exit router and then proceeds across the non-ATM part of the network by the normal means.
インターネットでのリソースの予約が送付者であるかもしれないという事実かセットアッププロトコルの詳細によって、開始された受信機はこの状況のジェネリック議論を難しくします。 セクション4でそれに戻るつもりですが、私たちは、当分この区別を言い繕うのを試みるつもりです。 私たちは、ユニキャストアプリケーションと、アプリケーションのトラフィックの特性とQoS要件(遅れ、損失、スループットなどの)が少なくとも1人のホストにとって知られていると思うつもりです。 そのホストは必要なQoSを求める要求と予想されたトラフィックの記述にネットワークに着手します。 何らかのポイントでは、この要求はATMネットワークの縁でルータを打ちます。 ルータは、要求を調べて、要求を光栄に思うのにATMネットワークの上の既存の接続を使用できなければならないかどうか、またはそれが新しい接続を確立しなければならないかどうか決めなければなりません。 後者の場合では、それは、どういうATM接続を開いたらよいかを決めて、必要なサービスをATMネットワークに説明するのにQoSとトラフィック特殊化を使用しなければなりません。 また、それは、どこに接続を開くかを決めなければなりません。 一度、接続が開かれて、要求は、ATMネットワークの向こう側に出口ルータに転送されて、次に、ネットワークの非ATM部分の向こう側に正常な手段で続きます。
We can see from the above description that there are several sets of issues to be discussed:
私たちは、上の記述から議論するために数セットの問題があるのを見ることができます:
* How does the IP service model, with certain service classes and
associated styles of traffic and QoS characterization, map onto
the ATM service model?
* あるサービスのクラスと関連スタイルのトラフィックとQoS特殊化で、IPサービスモデルはどのようにATMサービスモデルに写像しますか?
* How does the IP reservation model (whatever it turns out to be) map
onto ATM signalling?
* IP予約モデル(それが判明するものなら何でも)はどのようにATM合図に写像しますか?
* How does IP over ATM routing work when service quality is added to
the picture?
* サービス品質が画像に加えられるとき、ATMルーティングの上のIPはどのように扱いますか?
These issues will be discussed in the following sections.
以下のセクションでこれらの問題について議論するでしょう。
3.0 Service Model Issues
3.0 サービスモデル問題
There are several significant differences between the ways in which IP and ATM will provide QoS. When IP commits to provide a certain QoS to an application according to the Internet service model, it must be able to request an appropriate QoS from the ATM network using the ATM service model. Since these service models are by no means the same, a potentially complex mapping must be performed for the IP layer to meet its commitments. The details of the differences between ATM and IP and the problems presented by these differences are described below.
IPとATMがQoSを提供する方法の間には、いくつかの著しい違いがあります。 IPがインターネットのサービスモデルに応じて、あるQoSをアプリケーションに提供するために公約されるとき、それは、ATMネットワークからATMサービスモデルを使用することで適切なQoSを要求できなければなりません。 これらのサービスモデルが決して同じでないので、IP層が約束を守るために潜在的に複雑なマッピングを実行しなければなりません。 ATMとIPの違いの詳細とこれらの違いによって提示された問題は以下で説明されます。
Borden, et al Informational [Page 6] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[6ページ]RFC1821レアル-時間Service
We may think of a real-time service model as containing the following components:
私たちは以下のコンポーネントを含むとリアルタイムのサービスモデルを思うかもしれません:
* a way to characterize traffic (sometimes called the Tspec);
* トラフィック(時々Tspecと呼ばれる)を特徴付ける方法。
* a way to characterize the desired quality of service (the Rspec).
* 必要なサービスの質(Rspec)を特徴付ける方法。
We label these components as traffic characterization and QoS characterization. Each of these components is discussed in turn in the following sections.
私たちは、トラフィック特殊化としてのコンポーネントとこれらをラベルして、特殊化とQoSをラベルします。 以下のセクションで順番にそれぞれのこれらのコンポーネントについて議論します。
As well as these aspects of the service model, both ATM and IP will have a number of mechanisms by which the model is implemented. The mechanisms include admission control, policing, and packet scheduling. A particularly important mechanism is the one by which end-nodes communicate their QoS needs and traffic characteristics to the network, and the network communicates admission control decisions to the end-nodes. This is referred to as resource reservation or signalling, and is the subject of Section 4. In fact, it seems to be the only mechanism where significant issues of IP/ATM integration arise. The details of admission control, policing and packet scheduling are largely internal to a single network element and we do not foresee significant problems caused by the integration of IP and ATM. For example, while there may be plenty of challenges in designing effective approaches to admission control for both IP and ATM, it is not apparent that there are any special challenges for the IP over ATM environment. As the walk-through of Section 2.3 described, a reservation request from a host would at some point encounter the edge of the ATM cloud. At this point, either a new connection needs to be set up across the ATM cloud, or the router can decide to carry the requested traffic over an existing virtual circuit. If the ATM cloud cannot create a new connection as requested, this would presumably result in an admission control failure which would cause the router to deny the reservation request.
サービスモデルのこれらの局面と同様に、ATMとIPの両方には、モデルが実装される多くのメカニズムがあるでしょう。 メカニズムは入場コントロール、取り締まり、およびパケットスケジューリングを含んでいます。 特に重要なメカニズムはエンドノードがそれらのQoSの必要性とトラフィックの特性をネットワークに伝えるものです、そして、ネットワークは入場コントロール決定をエンドノードに伝えます。 これは、資源予約と呼ばれるか、または合図していて、セクション4の対象です。 事実上、それはIP/ATM統合の重要な問題が起こる唯一のメカニズムであるように思えます。 入場コントロール、取り締まり、およびパケットスケジューリングの詳細はただ一つのネットワーク要素に主に内部です、そして、私たちはIPとATMの統合で引き起こされた重大な問題について見通しません。 例えば、IPとATMの両方のための入場コントロールへの有効なアプローチを設計するのにおいて多くの挑戦があるかもしれませんが、ATM環境の上にどんなIPに、特別な挑戦もあるのは、明らかではありません。 セクション2.3の立ち稽古が説明したように、ホストからの予約の要請は何らかのポイントでATM雲の縁に遭遇するでしょう。 ここに、新しい接続が、ATM雲の向こう側にセットアップされる必要があるか、またはルータは、既存の仮想の回路の上まで要求されたトラフィックを運ぶと決めることができます。 ATM雲が要求された通り新しい接続を創造できないなら、おそらく、これはルータが予約の要請を否定する入場コントロール失敗をもたらすでしょう。
3.1 Traffic Characterization
3.1 トラフィック特殊化
The traffic characterization provided by an application or user is used by the network to make decisions about how to provide the desired quality of service to this application and to assess the effect the new flow will have on the service provided to existing flows. Clearly this information feeds into the admission control decision process.
アプリケーションかユーザによって提供されたトラフィック特殊化は、必要なサービスの質をこのアプリケーションに提供して、どう新しい流れが既存の流れに提供されたサービスのときに持っている効果を評価するかに関する決定をするのにネットワークによって使用されます。 明確に、この情報は入場コントロール決定プロセスに食べられます。
In the Internet community, it is assumed that traffic will in general be bursty and that bursty traffic can be characterized by a `token bucket'. While ATM does not expect all traffic to be bursty (the Continuous Bit Rate class being defined specifically for non-bursty
インターネットコミュニティでは、一般に、トラフィックがburstyになって、'トークンバケツ'でburstyトラフィックは特徴付けることができると思われます。 ATMが、すべてのトラフィックがburstyであると予想しない、(特に非burstyのために定義されるContinuous Bit Rateのクラス
Borden, et al Informational [Page 7] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[7ページ]RFC1821レアル-時間Service
traffic), it uses an essentially equivalent formulation for the characterization of traffic that is bursty, referred to as the Generic Cell Rate Algorithm (GCRA). However, ATM in some classes also requires specification of peak cell rate, whereas peak rates are not currently included in the IP traffic characterizations. It may be possible to use incoming interface speeds to determine an approximate peak rate.
トラフィック)、それはGeneric Cell Rate Algorithm(GCRA)と呼ばれたburstyであるトラフィックの特殊化に本質的には同等な定式化を使用します。 しかしながら、また、数人のクラスにおけるATMはピークセルレートの仕様を必要としますが、ピークレートは現在、IPトラフィック特殊化に含まれていません。 大体のピークレートを測定するのに入って来るインタフェース速度を使用するのは可能であるかもしれません。
One of the functions that must be performed in order to carry IP traffic over an ATM network is therefore a mapping from the characterization of the traffic as supplied to IP to a characterization that is acceptable for ATM. While the similarity of the two characterizations suggests that this is straightforward, there is considerable flexibility in the mapping of parameters from IP to ATM. As an extreme example, a router at the edge of an ATM cloud that expects to receive bursts of IP packets on a non-ATM interface, with the bursts described by some token bucket parameters, could actually inject ATM cells at a constant rate into the ATM network. This may be achieved without significant buffering if the ATM link speed is faster than the point-to-point link speed; alternatively, it could be achieved by buffering out the burstiness of the arriving traffic. It seems more reasonable to map an IP flow (or a group of flows) with variable bandwidth requirements onto an ATM connection that accommodates variable bit rate traffic. Determining how best to map the IP traffic to ATM connections in this way is an area that warrants investigation.
したがって、ATMネットワークの上までIPトラフィックを運ぶために実行しなければならない機能の1つはATMにおいて、許容できる特殊化へのIPに供給するようにトラフィックの特殊化からのマッピングです。 2つの特殊化の類似性は、これが簡単であると示唆しますが、パラメタに関するマッピングにはIPからATMまでかなりの柔軟性があります。 極端な例、それが予想するATM雲の縁のルータとして、炸裂がいくつかのトークンバケツパラメタによって説明されている状態で、非ATMインタフェースにおけるIPパケットの炸裂を受けるのは実際に一定の割合でATMネットワークにATMセルを注ぐかもしれません。 ATMリンク速度がポイントツーポイント接続速度より速いなら、これは重要なバッファリングなしで達成されるかもしれません。 あるいはまた、到着のburstinessからトラフィックをバッファリングすることによって、それを達成できるでしょう。 可変帯域幅要件でIP流動(または、流れのグループ)を可変ビット伝送速度トラフィックを収容するATM接続に写像するのは、より妥当に思えます。 このようにIPトラフィックをATM接続に写像するのが、どのように最もよく、調査を保証する領域であるかを決定します。
A potential complication to this process is the fact that the token bucket parameters are specified at the edge of the IP network, but that the specification of the GCRA parameters at the entry to an ATM network will frequently happen at a router in the middle of an IP network. Thus the actual burstiness that is encountered at the router may differ from that described by the IP token bucket parameters, as the burstiness changes as the traffic traverses a network. The seriousness of this problem needs to be understood to permit efficient resource utilization.
このプロセスへの合併症の可能性はトークンバケツパラメタがIPネットワークの縁で指定されますが、ATMネットワークへのエントリーのGCRAパラメタの仕様がIPネットワークの中央のルータで頻繁に起こるという事実です。 したがって、ルータで遭遇する実際のburstinessはIPトークンバケツパラメタによって説明されたそれと異なるかもしれません、トラフィックがネットワークを横断するのに応じてburstinessが変化するとき。 この問題の重大さは、効率的なリソース利用を可能にするのが理解される必要があります。
3.2 QoS Characterization
3.2 QoS特殊化
In addition to specifying the traffic that they will submit to the network, applications must specify the QoS they require from the network. Since the goal is to carry IP efficiently over ATM networks, it is necessary to establish mechanisms by which QoS specifications for IP traffic can be translated into QoS specifications that are meaningful for an ATM network.
彼らがネットワークに提出するトラフィックを指定することに加えて、アプリケーションは彼らがネットワークから必要とするQoSを指定しなければなりません。 目標が効率的にATMネットワークの上までIPを運ぶことであるので、ATMネットワークに、重要なQoS仕様にIPトラフィックのためのQoS仕様を翻訳できるメカニズムを確立するのが必要です。
Borden, et al Informational [Page 8] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[8ページ]RFC1821レアル-時間Service
The proposed method of QoS specification for the Internet is to specify a `service class' and some set of parameters, depending on the service class. The currently proposed service classes are
インターネットのためのQoS仕様の提案されたメソッドは'サービスのクラス'と何らかのセットのパラメタを指定することです、サービスのクラスによって。 現在提案されたサービスのクラスはそうです。
* guaranteed, which provides a mathematically guaranteed delay
bound [23];
* 保証されていて、どれが数学的に保証された遅れを提供するかが[23]を縛りました。
* predictive delay, which provides a probabilistic delay bound
[24];and
* 予言の遅れ(それは、確率的な遅れバウンド[24]を提供します)。
* controlled delay, which merely tries to provide several levels of
delay which applications may choose between [25].
* 制御遅れ。(その遅れは単に、それのアプリケーションが[25]を選ぶかもしれないいくつかのレベルの遅れを提供しようとします)。
These are in addition to the existing `best-effort' class. More IP service classes are expected in the future. ATM has five service classes:
これらは既存の'ベストエフォート型'のクラスに加えています。 より多くのIPサービスのクラスが将来、予想されます。 ATMには、5つのサービスのクラスがあります:
* CBR (constant bit rate), which emulates a leased line, providing
very tightly constrained delay and designed for applications which
can use a fixed bandwidth pipe;
* CBR(固定ビットレート)(CBRは非常にしっかり強制的な遅れを提供して、固定帯域幅パイプを使用できるアプリケーションのために設計された専用線を見習います)。
* VBR (variable bit rate)-real-time which attempts to constrain delay
for applications whose bandwidth requirements vary;
* VBR(可変ビット伝送速度)、リアルタイムで、帯域幅要件が異なるアプリケーションのために遅れを抑制するどの試み。
* VBR-non-real-time, intended for variable bandwidth applications
without tight delay constraints;
* VBR、非リアルタイムで、可変帯域幅アプリケーションのために、きつい遅れ規制なしで意図しています。
* UBR (unspecified bit rate) which most closely approximates the best
effort service of traditional IP;
* 最も密接に伝統的なIPのベストエフォート型サービスに近似するUBR(不特定のビット伝送速度)。
* ABR (available bit rate) which uses a complex feedback mechanism
to control loss.
* 損失を制御するのに複雑なフィードバック・メカニズムを使用するABR(有効なビット伝送速度)。
Each class requires some associated parameters to be specified, e.g., CBR requires a peak rate. Observe that these classes are by no means in direct correspondence with the IP classes. In some cases, ATM classes require parameters which are not provided at the IP level, such as loss rate, to be specified. It may be necessary to assume reasonable default values in these cases.
各クラスは、いくつかの関連パラメタが指定されるのを必要とします、例えば、CBRがピークレートを必要とします。 IPのクラスとのダイレクト通信でこれらのクラスが決してそうでないことを観測してください。 いくつかの場合、ATMのクラスは指定されるために損失率などのIPレベルで提供されないパラメタを必要とします。 これらの場合における妥当なデフォルト値を仮定するのが必要であるかもしれません。
The major problem here is this: given traffic in a particular IP service class with certain QoS parameters, how should it be sent across an ATM network in such a way that it both meets its service commitments and makes efficient use of the ATM network's resources? For example, it would be possible to transport any class of IP traffic over an ATM network using the constant bit rate (CBR) ATM class, thus using the ATM network like a point-to-point link. This would allow IP to meet its service commitments, but would be an
ここの大した問題はこれです: あるQoSパラメタがある特定のIPサービスのクラスにおけるトラフィックを考えて、それがサービス委任を満たして、ATMネットワークのリソースの効率的な使用をするのは、ATMネットワークの向こう側にどのようにそのような方法で送られるべきですか? 例えば、ATMネットワークの上でどんなクラスのIPトラフィックも輸送するのは固定ビットレート(CBR)ATMのクラスを使用することで可能でしょう、その結果、ポイントツーポイント接続のようにATMネットワークを使用します。 これは、IPがサービス委任を満たすのを許容するでしょうが、あるでしょう。
Borden, et al Informational [Page 9] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[9ページ]RFC1821レアル-時間Service
inefficient use of network resources in any case where the IP traffic was at all bursty (which is likely to be most cases). A more reasonable approach might be to map all IP traffic into a variable bit rate (VBR) class; certainly this class has the flexibility to accommodate bursty IP traffic more efficiently than CBR.
IPトラフィックがすべてのbursty(ほとんどのケースである傾向がある)にあったどんな場合でもネットワーク資源の効率の悪い使用。 より合理的なアプローチは可変ビット伝送速度(VBR)のクラスにすべてのIPトラフィックを写像することであるかもしれません。 確かに、このクラスには、CBRより効率的にbursty IPトラフィックを収容する柔軟性があります。
At present, the IETF is not working on any service classes in which loss rate is considered as part of the QoS specification. As long as that is the case, the fact that ATM allows target loss rates to be specified is essentially not an issue. However, we may certainly expect that as the IP service model is further refined, service classes that include specifications of loss may be defined. At this point, it will be necessary to be able to map between loss rates at the IP level and loss rates at the ATM level. It has already been shown that relatively small loss rates in an ATM network can translate to high loss rates in IP due to the fact that each lost cell can cause the loss of an entire IP packet. Schemes to mitigate this problem, which include the proposed approach to implementing the ABR class, as well as other solutions [22], have been proposed. This is clearly likely to be an important issue in the future.
現在のところ、IETFは損失率がQoS仕様の一部であるとみなされるどんなサービスのクラスにも勤めていません。 それがそうである限り、ATMが、目標損失率が指定されるのを許容するという事実は本質的には問題ではありません。 しかしながら、IPサービスモデルがさらに洗練されるとき、確かに、私たちはそれを予想するかもしれなくて、損失の仕様を含んでいるサービスのクラスは定義されるかもしれません。 ここに、それは、損失率の間でIPレベルと損失率でATMレベルで写像できるように必要になるでしょう。 それぞれの無くなっているセルが全体のIPパケットの損失をもたらすことができるのは事実のため、ATMネットワークにおける比較的わずかな損失率がIPで高い損失率に翻訳されることができるのが既に示されました。 この問題を緩和する計画、および他の解決策[22]は提案されました。(計画はABRのクラスを実行することへの提案されたアプローチを含んでいます)。 これは明確に将来切迫した課題である傾向があります。
4.0 Resource Reservation Styles
4.0 資源予約様式
ATM uses a signalling protocol (Q.2931) both to establish virtual connections and to allocate resources to those connections. It has many of the characteristics of a 'conventional' signalling protocol, such as being sender-driven and relying on hard-state in switches to maintain connections. Some of the key characteristics are listed in the table below. In the current standards, the QoS associated with a connection at setup time cannot be changed subsequently (i.e., it is static); in a unicast connection, resources are allocated in both directions along the path, while in the multicast case, they are allocated only from the sender to the receivers. In this case, all senders receive the same QoS.
ATMは、ともに仮想接続を証明して、それらの接続にリソースを割り当てるのに、合図プロトコル(Q.2931)を使用します。 それには、'従来'の合図プロトコルの特性の多くがあります、送付者が駆動であり、接続を維持するためにスイッチで固い状態を当てにしているのなどように。 主要な特性のいくつかが以下のテーブルに記載されています。 現在の規格では、次に、準備時間に接続に関連しているQoSを変えることができません(すなわち、それは静的です)。 ユニキャスト接続では、経路に沿った両方の方向にリソースを割り当てます、マルチキャスト場合では、それらを送付者だけから受信機まで割り当てますが。 この場合、すべての送付者が同じQoSを受け取ります。
Two protocols have been proposed for resource reservation in IP. The first (chronologically) is ST-II, the other is RSVP. Each of these, and its relationship to ATM, is discussed in the following sections.
2つのプロトコルがIPにおける資源予約のために提案されました。 1番目が(年代順に)ST-IIである、もう片方がRSVPです。 以下のセクションでそれぞれのこれら、およびATMとのその関係について議論します。
4.1 RSVP
4.1 RSVP
IP has traditionally provided connectionless service. To support real-time services in a connectionless world, RSVP has been proposed to enable network resources to be reserved for a connectionless data stream. ATM, on the other hand, provides a connection-oriented service, where resource reservations are made at connection setup time, using a user-network interface (UNI) and a network-network interface (NNI) signalling protocol.
IPはコネクションレス型サービスを伝統的に提供しました。 コネクションレスな世界でリアルタイムのサービスを支持するなら、RSVPは、ネットワーク資源がコネクションレスなデータ・ストリームのために予約されるのを可能にするために提案されました。 他方では、ATMは、資源予約が接続準備時間にされるところでユーザネットワーク・インターフェース(UNI)とネットワークネットワーク・インターフェース(NNI)合図プロトコルを使用することでコネクション型サービスを提供します。
Borden, et al Informational [Page 10] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[10ページ]RFC1821レアル-時間Service
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Receiver-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Soft state | Hard state |
| | (refresh/time-out) | (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Separate from | Concurrent with |
| | route establishment | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation|
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation|
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------
----------------------------------------------------------------- | カテゴリ| RSVP| 気圧(UNI3.0)| ----------------------------------------------------------------- | | | | | オリエンテーション| 受信機ベースです。| 送付者ベースです。| | | | | ---------------------------------------------------------------- | | | | | 状態| 軟性国家| 固い状態| | | (/タイムアウトをリフレッシュします) | (明白である、削除、) | ----------------------------------------------------------------- | | | | |QoS SetupTime| 別々| 同時発生| | | ルート設立| ルート設立| ----------------------------------------------------------------- | | | | |QoS変化? | ダイナミックなQoS| 静的なQoS| | | | (準備時間に、修理されています) | ----------------------------------------------------------------- | | | 双方向の配分| |方向性| 単方向| ユニキャストのために| | |資源配分|単方向の配分| | | | マルチキャストのために| ----------------------------------------------------------------- | | | | |異種性| 受信機| QoSを一様にします。| | | 異種性| すべての受信機| -----------------------------------------------------------------
The principles used in the design of RSVP differ from those of ATM in the following respects:
RSVPのデザインに使用される原則は以下の点においてATMのものと異なっています:
* Resource reservations in IP hosts and routers are represented by
soft state, i.e., reservations are not permanent, but time out
after some period. Reservations must be refreshed to prevent
time-out, and may also be explicitly deleted. In ATM, resources are
reserved for the duration of a connection, which must be explicitly
and reliably deleted.
* しかし、ホストとルータが軟性国家によって代理をされて、すなわち、予約が永久的でないというIPにおける資源予約、いつかの期間の後のタイムアウト。 予約は、タイムアウトを防ぐためにリフレッシュしなければならなくて、また、明らかに削除されるかもしれません。 ATMでは、リソースは接続の持続時間のために予約されます。(接続を明らかに、そして確かに削除しなければなりません)。
* The soft state approach of RSVP allows the QoS reserved for a flow
to be changed at any time, whereas ATM connections have a static
QoS that is fixed at setup time.
* 流れのために予約されたQoSはいつでも、RSVPの軟性国家アプローチで変化しますが、ATM接続は準備時間に修理されている静的なQoSを持っています。
* RSVP is a simplex protocol, i.e., resources are reserved in one
direction only. In ATM, connections (and associated reservations)
are bi-directional in point-to-point calls and uni-directional in
point-to-multipoint calls.
* RSVPがシンプレクスプロトコルである、すなわち、リソースは一方向だけに予約されます。 ATM、接続(そして、関連予約)、指すポイントでの双方向の呼び出しと多点へのポイントでのuni方向の呼び出しは中です。
Borden, et al Informational [Page 11] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[11ページ]RFC1821レアル-時間Service
* Resource reservation is receiver-initiated in RSVP. In ATM,
resources are reserved by the end system setting up the connection.
In point-to-multipoint calls, connection setup (and hence resource
reservation) must be done by the sender.
* 資源予約はRSVPで受信機によって開始されています。 ATMでは、リソースは接続をセットアップするエンドシステムによって予約されます。 多点へのポイントでは、呼び出しであり、送付者は接続設定(そして、したがって、資源予約)をしなければなりません。
* RSVP has explicit support for sessions containing multiple senders,
namely the ability to select a subset of senders, and to
dynamically switch between senders. No such support is provided
by ATM.
* RSVPには、複数の送付者を含むセッションの明白なサポート、送付者の部分集合を選択して、ダイナミックに送付者を切り換えるすなわち、能力があります。 どんなそのようなサポートもATMによって提供されません。
* RSVP has been designed independently of other architectural
components, in particular routing. Moreover, route setup and
resource reservation are done at different times. In ATM, resource
reservation and route setup are done at the same time (connection
setup time).
* RSVPは他の建築構成の如何にかかわらず特定のルーティングで設計されています。 そのうえ、いろいろな時間にルートセットアップと資源予約をします。 ATMでは、同時に(接続準備時間)、資源予約とルートセットアップをします。
The differences between RSVP and ATM state establishment, as described above, raise numerous problems. For example, since point- to-point connections are bidirectional in ATM, and since reservations can be made in both directions, receiver-initiated resource reservations in RSVP can be simulated in ATM by having the receiver set up the connection and reserve resources in the backward direction only. However, this is potentially wasteful of connection resources since connections are only ever used to transfer data in one direction even though communication between the two parties may be bidirectional. One option is to use a `point-to-multipoint' ATM connection with only one receiver. Of course, the fact that the RSVP reservation request is made by the receiver(s) means that this request must be somehow communicated to the sender on the ATM network. This is somewhat analogous to the receiver-oriented join operation of IP multicast and the problems of implementing it over ATM, as discussed in Section 6. In general, the efficiency of any proposed connection management scheme needs to be investigated in both unicast and multicast contexts for a range of application requirements, especially at a large scale.
RSVPとATM州の設立の上で説明される違いは多数の問題を提起します。例えば、ポイントとのポイント接続がATMで双方向であり、両方の方向の予約をすることができるので、受信機に接続と蓄えのリソースを逆方向だけにセットアップさせることによって、ATMでRSVPの受信機で開始している資源予約はシミュレートできます。 しかしながら、2回のパーティーのコミュニケーションが双方向であるかもしれませんが、接続が今までにデータを一方向に移すのに使用されるだけであるので、これは接続リソースで潜在的に無駄です。 1つのオプションは1台の受信機だけとの'ポイントツーマルチポイント'ATM接続を使用することです。もちろん、RSVP予約の要請が受信機によって作られるという事実はどうにかATMネットワークの送付者にこの要求を伝えなければならないことを意味します。 これは受信機指向にいくらか類似しています。IPマルチキャストの操作とATMの上でそれを実行するという問題に参加してください、セクション6で議論するように。 一般に、どんな提案された接続管理計画の効率も、さまざまなアプリケーション要件のためのユニキャストとマルチキャスト文脈の両方で調査される必要があります、特に大規模で。
The use by RSVP of `soft state' as opposed to explicit connections means that routers at the ATM network's edges need to manage the opening and closing of ATM connections when RSVP reservations are made and released (or time out). The optimal scheme for connection setup and tear-down will depend on the cost of setting up a connection versus the cost of keeping the connection open for possible future use by another stream, and is likely to be service class-dependent. For example, connections may be left open for reuse by best-effort traffic (subject to sufficient connections being available), since no resources are explicitly reserved. On the other hand, connections supporting the real-time service classes are likely to be expensive to leave open since resources may be allocated even
明白な接続と対照的に'軟性国家'のRSVPによる使用は、ATMネットワークの縁のルータが、RSVPの予約が作られていて、リリースされるとき(または、タイムアウト)、ATM接続の始まりと閉鎖を管理する必要を意味します。 接続設定と分解の最適の計画は、可能な今後の使用のために別の流れで接続対接続を開くように保つ費用をセットアップする費用に依存して、サービスクラス扶養家族である傾向があります。 例えば、ベストエフォート型交通(手があいている十分な接続を条件とした)で接続は再利用において開くままにされるかもしれません、リソースが全く明らかに予約されないので。 他方では、リアルタイムのサービスのクラスを支持している接続はリソースを割り当てさえするかもしれないので戸外を出るために高価である傾向があります。
Borden, et al Informational [Page 12] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[12ページ]RFC1821レアル-時間Service
when the connection is idle. Again, the cost incurred will depend on the class. For example, the cost of an open, idle `guaranteed' QoS connection is likely to be significantly more expensive than a connection providing predictive or controlled delay service. Note that connections can be reused for traffic of the same class with compatible QoS requirements, and that it may sometimes be possible to use a `higher quality' class to substitute for a lower quality one.
接続が無駄であるときに。 一方、被られた費用はクラスに依存するでしょう。 例えば、開いていて、無駄な'保証された'QoS接続の費用は予言的であるか制御された遅れサービスを提供する接続よりかなり高価である傾向があります。 コンパチブルQoS要件がある同じクラスの交通に接続を再利用できて、やや劣る品質1のために代理をするのに'より高い品質'クラスを使用するのが時々可能であるかもしれないことに注意してください。
Another characteristic of RSVP which presents problems for ATM is the use of PATH messages to convey information to receivers before any reservation is made. This works in IP because routing is performed independently of reservation. Delivery of PATH messages across an ATM network is therefore likely to require a mechanism for setting up connections without reservations being made. The connection also needs to be of sufficient quality to deliver PATH messages fairly reliably; in some circumstances, a low quality best effort service may be inadequate for this task. A related issue is the problem of advertising services prior to reservations. The OPWA model (one pass with advertising) requires network elements to advertise the QoS that they are able to provide so that receivers can decide what level of reservation to request. Since these advertisements may be made prior to any resources having been reserved in the ATM network, it is not clear how to make meaningful advertisements of the QoS that might be provided across the ATM cloud.
ATMのために問題を提示するRSVPの別の特性はどんな予約もする前に受信機に情報を伝達するPATHメッセージの使用です。 ルーティングが予約の如何にかかわらず実行されるので、これはIPで働いています。 配送..メッセージ..ネットワーク..したがって..ありそう..必要..メカニズム..セットアップ..接続..予約..作る また、接続は、メッセージをPATHにかなり確かに渡すことができるくらいの品質がある必要があります。 いくつかの事情では、低い上質のベストエフォート型サービスはこのタスクに不十分であるかもしれません。 関連する問題は予約の前の広告サービスの問題です。 OPWAモデル(広告がある1個のパス)は、受信機が、どんなレベルの予約を要求するかを決めることができるように、彼らが提供できるQoSの広告を出すためにネットワーク要素を必要とします。 ATMネットワークで予約されたどんなリソースの前にもこれらの広告をするかもしれないので、ATM雲の向こう側にどうQoSの重要な広告をそれにするかを提供するのは明確ではありません。
Finally, the multiparty model of communication is substantially different in RSVP and ATM. Emulating RSVP receiver-initiation using ATM point-to-multipoint connections is likely to cause severe scaling problems as the number of receivers becomes large. Also, some functions of RSVP are not currently provided by ATM. For example, there is no support for different receiver requirements and capabilities-all receivers in a session receive the same QoS, which is fixed at the time the first receiver is added to the multicast tree. It is likely that ATM support for multi-party sessions will be enhanced in later versions of the standards. It is necessary for such support to evolve in a manner compatible with RSVP and IP multicast routing protocols if large ATM clouds are to be deployed successfully.
最終的に、コミュニケーションの「マルチ-パーティー」モデルはRSVPとATMで実質的に異なっています。 受信機の数が大きくなるとき、ATMポイントツーマルチポイント接続を使用することでRSVP受信機開始を見習うのは厳しいスケーリング問題を引き起こしそうです。 また、RSVPのいくつかの機能は現在、ATMによって提供されません。 例えば、異なった受信機要件のサポートが全くありません、そして、セッションにおける能力すべて、受信機は最初の受信機がマルチキャスト木に加えられるとき固定されたのと同じQoSを受けます。 マルチパーティセッションのATMサポートは規格の後のバージョンで機能アップされそうでしょう。 大きいATM雲が首尾よく配備されるつもりであるなら、そのようなサポートがRSVPとのコンパチブル方法とIPマルチキャストルーティング・プロトコルで発展するのが必要です。
4.2 ST-II
標準時4.2II
ST-II [27] and ST2+ [12] (referred to generically as ST hereafter) have data distribution and resource reservation schemes that are similar to ATM in many respects.
ST-II[27]とST2+[12](一般的に今後STに言及される)には、あらゆる点でATMと同様の情報配給と資源予約計画があります。
* ST is connection oriented using "hard state". Senders set up
simplex data flows to all receivers closely matching point-to-
multipoint connections in ATM. Routing decisions are made when
* STは「固い状態」を使用することで適応する接続です。 送付者は、ATMで密接にポイントからマルチポイント接続に合いながら、すべての受信機にシンプレクスデータフローをセットアップします。 ルート設定決定をする、いつ
Borden, et al Informational [Page 13] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[13ページ]RFC1821レアル-時間Service
the connection is made and are not changed unless there is a
failure in the path. Positive acknowledgment is required from all
receivers. ST2+ [12] adds a receiver-based JOIN mechanism that can
reduce the burden on senders to track all receivers.
失敗が経路にない場合、接続は、作られていて、変えられません。 肯定応答がすべての受信機から必要です。 ST2+[12]はすべての受信機を追跡するために送付者で負担を減少させることができる受信機ベースのJOINメカニズムを加えます。
* ST reserves network resources at connection setup time. The ST
CONNECT message contains a flowspec indicating the resources to be
reserved for the stream. Agents along the path may change the
flowspec based on restrictions they may need to impose on the
stream. The final flowspec is returned to the sender in the ACCEPT
message from each receiver or target.
* STは接続準備時間にネットワーク資源を予約します。 ST CONNECTメッセージは流れのために予約されるためにリソースを示すflowspecを含んでいます。 経路に沿ったエージェントは彼らが流れにでしゃばるために必要とするかもしれない制限に基づくflowspecを変えるかもしれません。 最終的なflowspecを各受信機か目標からACCEPTメッセージの送付者に返します。
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Sender-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Hard state | Hard state |
| | (explicit disconnect)| (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Concurrent with | Concurrent with |
| | stream setup | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation|
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation|
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------
----------------------------------------------------------------- | カテゴリ| RSVP| 気圧(UNI3.0)| ----------------------------------------------------------------- | | | | | オリエンテーション| 送付者ベースです。| 送付者ベースです。| | | | | ---------------------------------------------------------------- | | | | | 状態| 固い状態| 固い状態| | | (明白な分離)| (明白である、削除、) | ----------------------------------------------------------------- | | | | |QoS SetupTime| 同時発生| 同時発生| | | 流れのセットアップ| ルート設立| ----------------------------------------------------------------- | | | | |QoS変化? | ダイナミックなQoS| 静的なQoS| | | | (準備時間に、修理されています) | ----------------------------------------------------------------- | | | 双方向の配分| |方向性| 単方向| ユニキャストのために| | |資源配分|単方向の配分| | | | マルチキャストのために| ----------------------------------------------------------------- | | | | |異種性| 受信機| QoSを一様にします。| | | 異種性| すべての受信機| -----------------------------------------------------------------
These similarities make mapping ST services to ATM simpler than RSVP but the mapping is still not trivial. The task of mapping the ST flowspec into an ATM service class still has to be worked out. There may be policy issues related to opening a new VC for each stream versus aggregating flows over an existing VC.
これらの類似性で、まだに関するRSVPにもかかわらず、マッピングより簡単なATMに対するSTサービスを写像するのは些細になりません。 ATMサービスのクラスにST flowspecを写像するタスクはまだ解決されなければなりません。 既存のVCの上の流れに集めることに対して各流れのために新しいVCを開くと関連する政策問題があるかもしれません。
Borden, et al Informational [Page 14] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[14ページ]RFC1821レアル-時間Service
Additionally, ST has some differences with UNI 3.1 that can cause problems when integrating the two protocols:
さらに、STには、2つのプロトコルを統合するとき問題を起こすことができるUNI3.1があるいくつかの違いがあります:
* In ST, changes to active stream reservations are allowed. For
example, if the flowspec received from the target is not sufficient
for the stream, the sender can send a CHANGE message, requesting a
different QoS. UNI 3.1 does not allow changes to the QoS of a VC
after it is set up. Future ATM UNI specifications are contemplating
allowing changes to a VC after set up but this is still preliminary.
In the meantime, policies for over reservation or aggregation onto
a larger VC may be needed.
* STでは、活発な流れの予約への変化は許容されています。 例えば、目標から受け取られたflowspecが流れに十分でないなら、送付者はCHANGEメッセージを送ることができます、異なったQoSを要求して。 それがセットアップされた後にUNI3.1はVCのQoSへの変化を許容しません。 将来のATM UNI仕様はセットアップされた後にVCへの変化を許容すると熟考することですが、これはまだ予備です。 差し当たり、方針、VCがaにより大きい予約か集合で必要であるかもしれないので。
* ST uses simplex streams that flow in only one direction. This is
fine for UNI 3.1 point-to-multipoint connections since the data flow
is only in one direction. When mapping a point-to-point ST
connection to a standard point-to-point ATM VC, the reverse flow
connection is wasted.
* STは一方向だけに流れるシンプレクスの流れを使用します。 これは一方向だけにはデータフローがあるのでUNI3.1ポイントツーマルチポイントのために接続に罰金を課すことです。 二地点間ST接続を標準の二地点間ATM VCに写像するとき、逆の流れ接続は無駄です。
This can be solved simply by using only point-to-multipoint VCs, even if there is only one receiver.
単に1台の受信機しかなくてもポイントツーマルチポイントだけVCsを使用することによって、これを解決できます。
4.3 Mapping IP flows to ATM connections
4.3 IPを写像するのはATM接続に注ぎます。
In general, there will be a great deal of flexibility in how one maps flows at the IP level to connections at the ATM level. For example, one could imagine setting up an ATM connection when a reservation message arrives at the edge of an ATM cloud and then tearing it down as soon as the reservation times out. However, to minimize latency or perhaps for economic reasons, it may be preferable to keep the ATM connection up for some period in case it is needed. Similarly, it may be possible or desirable to map multiple IP flows to a single ATM connection or vice versa.
一般に、1つがIPレベルで流れをどう接続にATMレベルで写像するかの多くの柔軟性があるでしょう。 例えば、人は、予約メッセージがATM雲の縁に到着するとき、ATM接続をセットアップして、次に、予約時間の次第外までそれを取りこわすと想像できました。 しかしながら、それが必要であるといけないので、潜在を最小にするか、または恐らく経済的理由によって望ましいように、いつかの期間、ATM接続を続けるのは望ましいかもしれません。 単独のATM接続への複数のIP流れを写像するのが同様に、可能であるか、望ましいかもしれないか、逆もまた同様です。
An interesting situation arises when a reservation request is received for an existing route across the cloud but which, when added to the existing reservations using that connection, would exceed the capacity of that connection. Since the current ATM standards do not allow the QoS of a connection to be changed, there are two options: tear down the old connection and create a new one with the new, larger allocation of resources, or simply add a new connection to accommodate the extra traffic. It is possible that the former would lead to more efficient resource utilization. However, one would not wish to tear down the first connection before the second was admitted, and the second might fail admission control because of the resources allocated to the first. The difficulties of this situation seem to argue for evolution of ATM standards to support QoS modification on an existing connection.
雲の向こう側に既存のルートに予約の要請を受け取るとき、おもしろい状況は起こりますが、その接続を使用することで既存の予約に加えられると、どれがその接続の容量を超えているでしょうか? 接続のQoSが現在のATM規格で変化しないので、2つのオプションがあります: 年取った接続を取りこわしてください、そして、リソースの新しくて、より大きい配分がある新しいものを作成するか、または単に新しい接続を加えて、余分な交通に対応してください。 前者が、より効率的なリソース利用につながるのは、可能です。 しかしながら、2番目が認められて、2番目が1日に割り当てられたリソースで入場コントロールに失敗するかもしれない前に人は最初の接続を取りこわしたがっていないでしょう。 この状況の困難は既存の接続のときにQoS変更を支持するためにATM規格の発展について賛成の議論をするように思えます。
Borden, et al Informational [Page 15] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[15ページ]RFC1821レアル-時間Service
5.0 End System Issues
5.0 終わりのシステム銘柄
In developing an integrated IP-ATM environment the applications need to be as oblivious as possible of the details of the environment: the applications should not need to know about the network topology to work properly. This can be facilitated first by a common application programing interface (API) and secondly by common flow and filter specifications [18].
統合IP-ATM環境を開発する際に、アプリケーションは、できるだけ環境の詳細に気づかない必要があります: アプリケーションは、ネットワーク形態に関して適切に働くのを知る必要はないはずです。 これは、最初に、一般的なアプリケーションプログラミングインタフェース(API)によって容易にされて、第二に一般的で流れて、仕様[18]をフィルターにかけることができます。
An example of a common API that is gaining momentum is the BSD sockets interface. This is a UNIX standard and, with Winsock2, has also become a PC standard. With the IETF integrated service environment just beginning to appear in the commercial marketplace, the ability to standardize on one common interface for both IP and ATM applications is still possible and must be seriously and quickly pursued to insure interoperability.
はずみがつく予定である一般的なAPIに関する例はBSDソケットインタフェースです。 これは、UNIX規格であり、また、Winsock2と共にPC規格になりました。 IETFの統合サービス環境が商業市場にただ現れ始めている状態で、IPとATMアプリケーションの両方のために1つの一般的なインタフェースで標準化する能力をまだ可能であり、相互運用性を保障するために真剣にすぐに追求しなければなりません。
Since the IP integrated service and ATM environments offer different QoS service types, an application should specify sufficient information in its flow specification so that regardless of the topology of the network, the network can choose an acceptable QoS type to meet the applicationUs needs. Making the application provide sufficient information to quantify a QoS service and allowing the network to choose the QoS service type is essential to freeing the application from requiring a set network topology and allowing the network to fully utilize the features of IP and ATM.
IPの統合サービスとATM環境が異なったQoSサービスタイプを提供するので、アプリケーションはネットワークがネットワークのトポロジーにかかわらずapplicationUs需要を満たすために許容QoSタイプを選ぶことができるように、流れ仕様による十分な情報を指定するべきです。 セットネットワーク形態を必要とするのからアプリケーションを解放して、ネットワークがIPとATMの特徴を完全に利用するのを許容するのにアプリケーションにQoSサービスを定量化するために十分な情報を提供させて、ネットワークがQoSサービスタイプを選ぶのを許容するのは不可欠です。
6.0 Routing Issues
6.0 ルート設定問題
There is a fundamental difference between the routing computations for IP and ATM that can cause problems for real-time IP services. ATM computes a route or path at connection setup time and leaves the path in place until the connection is terminated or there is a failure in the path. An ATM cell only carries information identifying the connection and no information about the actual source and destination of the cell. In order to forward cells, an ATM device needs to consult a list of the established connections that map to the next hop device, without checking the final destination.
リアルタイムのIPサービスのために問題を起こすことができるIPとATMのためのルーティング計算の間には、基本的な違いがあります。 ATMは接続準備時間にルートか経路を計算して、接続が終えられるか、または失敗が経路にあるまで、適所で経路を出ます。 接続を特定する情報を運びますが、ATMセルはセルの実際のソースと目的地のどんな情報も運ぶだけではありません。 セルを進めるために、ATM装置は、ホップ装置、次への照合のない最終的な目的地を写像する確立した接続のリストに相談する必要があります。
In contrast, routing decisions in IP are based on the destination address contained in every packet. This means that an IP router, as it receives each packet, has to consult a table that contains the routes to all possible destinations and the routing decision is made based on the final destination of the packet. This makes IP routing very robust in the face of path changes and link failures at the expense of the extra header information and the potentially larger table lookup. However, if an IP path has been selected for a given QoS, changes in the route may mean a change in the QoS of the path.
対照的に、IPでのルーティング決定はあらゆるパケットに含まれた送付先アドレスに基づいています。 これは、各パケットを受けるときIPルータがすべての可能な目的地にルートを含むテーブルに相談しなければならないことを意味します、そして、パケットの最終的な目的地に基づいてルーティング決定をします。 これで、IPルーティングは経路変化とリンクの故障に直面して余分なヘッダー情報と潜在的により大きい索表を犠牲にして非常に強健になります。 しかしながら、IP経路が与えられたQoSのために選択されたなら、ルートの変化は経路のQoSにおける変化を意味するかもしれません。
Borden, et al Informational [Page 16] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[16ページ]RFC1821レアル-時間Service
6.1 Multicast routing
6.1 マルチキャストルーティング
Considerable research has gone into overlaying IP multicast models onto ATM. In the MARS (Multicast Address Resolution Server) model [1], a server is designated for the Logical IP Subnet (LIS) to supply the ATM addresses of the hosts in the IP multicast group, much like the ATM ARP server [15]. When a host or router wishes to send to a multicast group on the LIS, a query is made to the MARS and a list of the ATM address of the hosts or routers in the group is returned. The sending host can then set up point-to-point or point-to-multipoint VCs to the other group members. When a host or a router joins an IP multicast group, it notified the MARS. Each of the current senders to the group is then notified of the new group member so that the new member can be added to the point to multipoint VC's.
かなりの研究にIPマルチキャストモデルをATMにかぶせるために入りました。 火星(マルチキャストAddress Resolution Server)モデル[1]では、Logical IP Subnet(LIS)がIPマルチキャストグループでホストのATMアドレスを供給するように、サーバは指定されます、ATM ARPサーバ[15]のように。 ホストかマルチキャストに発信するというルータ願望がLISで分類されるとき、質問を火星にします、そして、グループにおけるホストかルータのATMアドレスのリストを返します。 そして、送付ホストは他のグループのメンバーにポイントツーポイントかポイントツーマルチポイントVCsをセットアップできます。 ホストかルータがIPマルチキャストグループに加わるとき、それは火星に通知しました。 そして、グループへの現在の送付者各人は、多点VCのものへのポイントに新しいメンバーを追加できるように新しいグループのメンバーについて通知されます。
As the number of LIS hosts and multicast groups grows, the number of VCs needed for a one-to-one mapping of VCs to multicast groups can get very large. Aggregation of multicast groups onto the same VC may be necessary to avoid VC explosion. Aggregation is further complicated by the QoS that may be needed for particular senders in a multicast group. There may be a need to aggregate all the multicast flows requiring a certain QoS to a set of VCs, and parallel VCs may be necessary to add flows of the same QoS.
LISホストとマルチキャストグループの数が成長するとき、マルチキャストグループへのVCsに関する1〜1つのマッピングに必要であるVCsの数は非常に大きくなることができます。 同じVCへのマルチキャストグループの集合が、VC爆発を避けるのに必要であるかもしれません。 集合はマルチキャストグループの特定の送付者に必要であるかもしれないQoSによってさらに複雑にされます。 VCsの1セットに、あるQoSを必要とするすべてのマルチキャスト流れに集める必要があるかもしれません、そして、平行なVCsが、同じQoSの流れを加えるのに必要であるかもしれません。
6.2 QoS Routing
6.2 QoSルート設定
Most unicast and multicast IP routing protocols compute the shortest path to a destination based solely on a hop count or metric. OSPF [16] and MOSPF [17] allow computation based on different IP Type of Service (TOS) levels as well as link metrics, but no current IP routing protocols take into consideration the wide range of levels of quality of service that are available in ATM or in the Integrated Services models. In many routing protocols, computing all the routes for just the shortest path for a large network is computationally expensive so repeating this process for multiple QoS levels might be prohibitively expensive.
ほとんどのユニキャストとマルチキャストIPルーティング・プロトコルが目的地に唯一ホップカウントに基づくか、またはメートル法で最短パスを計算します。 OSPF[16]とMOSPF[17]はService(TOS)レベルの異なったIP Typeに基づく計算にもかかわらず、リンク測定基準を考慮に入れますが、ルーティング・プロトコルが考慮に入れないどんな現在のIPも広範囲のサービスの質のATMかIntegrated Servicesモデルで利用可能なレベルを許容します。 多くのルーティング・プロトコルでは、大きいネットワークがしたがって、複数のQoSレベルのためにこの過程を繰り返しながら計算上高価であるので、まさしく最短パスのためにすべてのルートを計算するのは法外に高価であるかもしれません。
In ATM, the Private Network-to-Network Interface (PNNI) protocol [13] communicates QoS information along with routing information, and the network nodes can utilize this information to establish paths for the required QoS. Integrated PNNI (I-PNNI) [9] has been proposed as a way to pass the QoS information available in ATM to other routing protocols in an IP environment.
ATMでは、兵士のNetworkからネットワークへのInterface(PNNI)プロトコル[13]はルーティング情報に伴うQoS情報を伝えます、そして、ネットワーク・ノードは必要なQoSのために経路を証明するのにこの情報を利用できます。 統合PNNI(I-PNNI)[9]はATMでIP環境で他のルーティング・プロトコルに利用可能なQoS情報を通過する方法として提案されました。
Wang & Crowcroft [28] suggest that only bandwidth and delay metrics are necessary for QoS routing and this would work well for computing a route that required a particular QoS at some setup time, but this goes against the connectionless Internet model. One possible solution
ワングとクロウクロフト[28]は、帯域幅と遅れ測定基準だけがQoSルーティングに必要であり、これがいくらかの準備時間に特定のQoSを必要としたルートを計算するのにうまくいくと示唆しますが、これはコネクションレスなインターネットモデルに反します。 1つの可能な解決策
Borden, et al Informational [Page 17] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[17ページ]RFC1821レアル-時間Service
to the exhaustive computation of all possible routes with all possible QoS values would be to compute routes for a common set of QoS values and only then compute routes for uncommon QoS values as needed, extracting a performance penalty only on the first packets of a flow with an uncommon QoS. Sparse multicast routing protocols that compute a multicast path in advance or on the first packets from a sender (such as CBT [5] and MOSPF [17]) could also use QoS routing information to set up a delivery tree that will have adequate resources.
すべての可能なQoSとのすべての可能なルートの徹底的な計算に、値は計算するために、珍しいQoS値のために必要であるように一般的なQoS値のために発送して、ルートはその時計算されるだけです、珍しいQoSと共に流れの最初のパケットだけの上でパフォーマンスに不利な条件を抽出してことでしょう。 プロトコルを発送して、それは送付者からあらかじめか最初のパケットの上のマルチキャスト経路を計算します。まばらなマルチキャスト、(そのようなものには、また、CBT[5]とMOSPF[17])が配送木にそれを設定するのにQoSルーティング情報を使用できたように、適切なリソースがあるでしょう。
However, no multicast routing protocols allow the communication of QoS information at tree setup time. Obtaining a tree with suitable QoS is intended to be handled by RSVP, usually after the distribution tree has been set up, and may require recomputation of the distribution tree to provide the requested QoS.One way to solve this problem is to add some "hints" to the multicast routing protocols so they can get an idea of the QoS that the multicast group will require at group initiation time and set up a distribution tree to support the desired QoS. The CBT protocol [5] has some TBD fields in its control headers to support resource reservation. Such information could also be added to a future IGMP [11] JOIN message that would include information on the PIM Rendezvous Point (RP) or CBT Core.
しかしながら、どんなマルチキャストルーティング・プロトコルも木の準備時間にQoS情報に関するコミュニケーションを許容しません。 適当なQoSと共に木を得るのはRSVPによって扱われることを意図します、通常、分配木がセットアップされて、マルチキャストグループが必要なQoSを支持するために分配木にグループ開始時間に必要であり、セットするつもりであったのを彼らがQoSを理解できるようにいくつかの「ヒント」をマルチキャストルーティング・プロトコルに追加するこの問題を解決するのが、ことである要求されたQoS.One方法で前提とするために分配木を再計算に要求したかもしれない後に。 CBTプロトコル[5]は、資源予約を支持するためにコントロールヘッダーにいくつかのTBD分野を持っています。 また、PIM Rendezvous Point(RP)かCBT Coreの情報を含んでいる将来のIGMP[11]JOINメッセージにそのような情報を追加できました。
Another alternative is to recompute the multicast distribution tree based on the RSVP messages but this has the danger of losing data during the recomputation. However, this can leave a timing window where other reservations can come along during the tree recomputation and use the resources of the new path as well as the old path, leaving the user with no path to support the QoS desired.
マルチキャスト分配木がRSVPメッセージに基礎づけたrecomputeには別の代替手段がありますが、これでは、再計算の間、データを失うという危険があります。 しかしながら、どんな経路もユーザに残さないで、これは、QoSが望んでいたサポートに他の予約が木の間にやって来ることができるタイミングウィンドウを再計算に出て、古い経路と同様に新しい経路に関するリソースを使用できます。
If unicast routing is used to support multicast routing, we have the same problem of only knowing a single path to a given destination with no QoS information. If the path suggested by unicast routing does not have the resources to support the QoS desired, there are few choices available. Schemes that use an alternate route to "guess" at a better path have been suggested and can work for certain topologies but an underlying routing protocol that provides QoS information is necessary for a complete solution. As mentioned earlier, I-PNNI has the potential to provide enough information to compute paths for the requested QoS.
ユニキャストルーティングがマルチキャストルーティングをサポートするのに使用されるなら、私たちには、QoS情報なしでただ一つの経路を与えられた目的地に知っているだけの同じ問題があります。 ユニキャストルーティングで示された経路がQoSが望んでいたサポートにリソースを持っていないなら、利用可能な選択がわずかしかありません。 より良い経路で「推測すること」に代替経路を使用する体系は、示されて、あるtopologiesにうまくいくことができますが、情報をQoSに供給する基本的なルーティング・プロトコルが完全解に必要です。 先に述べたように、I-PNNIには、要求されたQoSのために経路を計算できるくらいの情報を提供する可能性があります。
6.3 Mobile Routing
6.3 モバイルルート設定
In developing an integrated IP-ATM network, potential new growth areas need to be included in the planning stages. One such area is mobile networking. Under the heading of mobile networks are included satellite extensions of the ATM cloud, mobile hosts that can join an IP subnetwork at random, and a true mobile network in which all
統合IP-ATMネットワークを発展させる際に、潜在的腫瘍領域は、計画段階に含まれる必要があります。 そのような領域の1つはモバイルネットワークです。 ネットワークがモバイルに関する見出しの下では、ATM雲の含まれている衛星拡大と、無作為にIPサブネットワークに加わることができるモバイルホストと、中の正しいモバイルネットワークである、どれ、すべて
Borden, et al Informational [Page 18] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[18ページ]RFC1821レアル-時間Service
network components including routers and/or switches are mobile.
ルータ、そして/または、スイッチを含むネットワーク要素モバイルです。
The IP-ATM real-time service environment must be extended to include mobile networks so as to allow mobile users to access the same services as fixed network users. In doing so, a number of problems exist that need to be addressed. The principle problems are that mobile networks have constrained bandwidth compared to fiber and mobile links and are less stable than fixed fiber links. The impact of these limitations affect IP and ATM differently. In introducing one or more constrained components into the ATM cloud,the effects on congestion control in the overall network are unknown. One can envision significant buffering problems when a disadvantaged user on a mobile link attempts to access information from a high speed data stream. Likewise, as ATM uses out of band signalling to set up the connection, the stability of the mobile links that may have significant fading or complete loss of connectivity could have a significant effect on ATM performance.
同じくらいがネットワーク利用者に修理されているように修理するアクセスにモバイルユーザを許容するためにモバイルネットワークを含むようにIP-ATMのリアルタイムのサービス環境を広げなければなりません。 そうする際に、扱われる必要がある多くの問題が存在しています。 原則問題は、ファイバーとモバイルリンクと比べて、モバイルネットワークが帯域幅を抑制したということであり、ファイバーリンクが修理されているほど安定していません。 これらの制限の影響はIPとATMに異なって影響します。 1つ以上の強制的なコンポーネントをATM雲に導入するのにおいて、総合的なネットワークにおける輻輳制御への効果は未知です。 モバイルリンクの上の不都合なユーザが、高速データ・ストリームから情報にアクセスするのを試みるとき、人は重要なバッファリング問題を思い描くことができます。 同様に、接続に設定するバンド合図からのATM用途として、重要な色あせを持っているかもしれないモバイルリンクの安定性か接続性の全損がATM性能に重要な影響を与えるかもしれません。
For QoS, fading on a link will appear as a varying channel capacity. This will result in time-dependent fluctuations of available links to support a level of service. Current routing protocols are not designed to operate in a rapidly changing topology. QoS routing protocols that can operate in a rapidly changing topology are required and need to be developed.
QoSに関しては、リンクで色あせるのは異なったチャネル容量として現れるでしょう。 これは、サービスのレベルをサポートするために利用可能なリンクの時間依存する変動に結果として生じるでしょう。 現在のルーティング・プロトコルは、急速に変化しているトポロジーで作動するように設計されていません。 急速に変化しているトポロジーで作動できるQoSルーティング・プロトコルは、必要であり、開発される必要があります。
7.0 Security Issues
7.0 セキュリティ問題
In a quality of service environment where network resources are reserved, hence potentially depriving other users access to these resources for some time period, authentication of the requesting host is essential. This problem is greatly increased in a combined IP-ATM topology where the requesting host can access the network either through the IP or the ATM portion of the network. Differences in the security architectures between IP and ATM can lead to opportunities to reserve resources without proper authorization to do so. A common security framework over the combined IP-ATM topology would be desirable. In lieu of this, the use of trusted edge devices requesting the QoS services are required as a near term solution.
ネットワーク資源が予約されて、したがってしばらくこれらのリソースへの他のユーザアクセスから潜在的に奪っているサービスの質環境で、期間、要求ホストの認証は不可欠です。 この問題は要求ホストがネットワークのIPかATM部分を通ってネットワークにアクセスできる結合したIP-ATMトポロジーで大いに増強されます。 IPとATMの間のセキュリティー体系の違いはそうするために適切な承認なしでリソースを予約する機会につながることができます。 結合したIP-ATMトポロジーの上の共通の安全保障フレームワークは望ましいでしょう。 これの代わりに、QoSサービスを要求する信じられたエッジデバイスの使用が短期間ソリューションとして必要です。
Significant progress in developing a common security framework for IP is underway in the IETF [2]. The use of authentication headers in conjunction with appropriate key management is currently being considered as a long range solution to providing QoS security [3,8]. In developing this framework, the reality of ATM portions of the Internet should be taken into account. Of equal importance, the ATM Forum ad-hoc security group should take into account the current work on an IP security architecture to ensure compatibility.
IPのために共通の安全保障フレームワークを開発することにおける重要な進歩はIETF[2]で進行中です。 適切なかぎ管理に関連した認証ヘッダーの使用は現在、セキュリティ[3、8]をQoSに供給することへの長い範囲ソリューションであるとみなされています。 このフレームワークを開発する際に、インターネットのATM部分の現実は考慮に入れられるべきです。 等しい重要性では、ATM Forumの臨時のセキュリティグループは、互換性を確実にするためにIPセキュリティー体系への執筆中の作品を考慮に入れるべきです。
Borden, et al Informational [Page 19] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[19ページ]RFC1821レアル-時間Service
8.0 Future Directions
8.0 将来の方向
Clearly, there are some challenging issues for real-time IP-ATM services and some areas are better understood than others. For example, mechanisms such as policing, admission control and packet or cell scheduling can be dealt with mostly independently within IP or ATM as appropriate. Thus, while there may be hard problems to be solved in these areas that need to be addressed in either the IP or ATM communities, there are few serious problems that arise specifically in the IP over ATM environment. This is because IP does not particularly care what mechanisms a network element (such as an ATM network) uses to provide a certain QoS; what matters is whether the ATM service model is capable of offering services that can support the end-to-end IP service model. Most of the hard problems for IP over ATM therefore revolve around the service models for IP and ATM. The one piece of mechanism that is important in an IP/ATM context is signalling or resource reservation, a topic we return to below.
明確に、リアルタイムのIP-ATMサービスのためのいくつかのやりがいがある問題があって、いくつかの領域が他のものよりより理解されています。 例えば、IPかATMの中で独自に適宜取り締まりや入場コントロールやパケットやセルスケジューリングなどのメカニズムにほとんど対処できます。 したがって、IPかATM共同体で扱われる必要があるこれらの領域で解決するべき難問があるかもしれませんが、ATM環境の上に特にIPで起こる深刻な問題はわずかしかありません。 これはIPが、ネットワーク要素(ATMネットワークなどの)が、あるQoSを提供するのにどんなメカニズムを使用するかを特に気にかけないからです。 ATMサービスモデルがそれをサービスに提供できるか否かに関係なく、問題が何であるかということであることは終わりから終わりへのIPサービスモデルをサポートできます。 したがって、ATMの上のIPのための難問の大部分はIPとATMのためにサービスモデルを中心題目とします。 1つのIP/ATM文脈で重要なメカニズムが、合図か資源予約(以下の私たちが戻る話題)です。
The following paragraphs enumerate some of the areas in which we believe significant work is needed. The work falls into three areas: extending the IP over ATM standards; extensions to the ATM service model; and extensions to the IP service model. In general, we expect that practical experience with providing IP QoS over ATM will suggest more enhancements to the service models.
以下のパラグラフは私たちが、重要な仕事が必要であると信じている領域のいくつかを列挙します。 仕事は3つの領域に落ちます: ATM規格の上でIPを広げています。 ATMサービスへの拡大はモデル化されます。 そして、IPサービスへの拡大はモデル化されます。 一般に、私たちは、IP QoSをATMの上に供給する実用的な経験が、より多くの増進をサービスモデルに示すと予想します。
We need to define ways of mapping the QoS and traffic characterizations (Tspecs and Rspecs) of IP flows to suitable characterizations for ATM connections. An agreement is needed so that some sort of uniform approach is taken. Whatever agreement is made for such mappings, it needs to be done so that when traversing several networks, the requested QoS is obtained end-to-end (when admission is possible). Practical experience should be gained with these mappings to establish that the ATM service classes can in fact provide suitable QoS to IP flows in a reasonably efficient way. Enhancement of the ATM service classes may be necessary, but experience is needed to determine what is appropriate.
私たちは、QoSを写像する方法を定義する必要があります、そして、IPのトラフィック特殊化(TspecsとRspecs)はATM接続のために適当な特殊化に注ぎます。 協定が必要であるので、ある種の一定のアプローチを取ります。 そのようなマッピングのためにされるどんな協定、するのが必要であるのでも、いくつかのネットワークを横断するとき、要求されたQoSは得られた終わりから終わり(入場が可能であるときに)です。 これらのマッピングで実用的な経験をして、事実上、ATMサービスのクラスがかなり効率的な方法で適当なQoSをIP流れに提供できると証明するべきです。 ATMサービスのクラスの増進が必要であるかもしれませんが、経験が、何が適切であるかを決定するのに必要です。
We need to determine how the resource reservation models of IP (RSVP and ST-II) interact with ATM signalling. Mechanisms for establishing appropriate connection state with suitable QoS in ATM networks that are part of a larger integrated services Internet need to be defined. It is possible that the current IP/ATM mechanisms such as ARP servers and MARS can be extended to help to manage this state.
私たちは、IP(RSVPとST-II)の資源予約モデルがどのようにATM合図と対話するかを決定する必要があります。 適当なQoSと共に、より大きい統合サービスインターネットの一部であるATMネットワークに適切な接続状態を設置するためのメカニズムは、定義される必要があります。 この状態を経営するのを助けるためにARPサーバや火星などの現在のIP/ATMメカニズムを広げることができるのは可能です。
There is a need for better QoS routing. While this functionality is needed even in the pure ATM or pure IP environment, there is also an eventual need for integrated QoS routing between ATM and IP. Further
より良いQoSルーティングの必要があります。 この機能性が純粋なATMか純粋なIP環境でさえ必要ですが、また、ATMとIPの間には、統合QoSルーティングの最後の必要があります。 一層
Borden, et al Informational [Page 20] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[20ページ]RFC1821レアル-時間Service
research and practical experience is needed in the areas of QoS routing in IP in order to support more than the shortest best-effort path, especially when this path may traverse ATM networks. In many IP networks, there are multiple paths between a given source and destination pair but current routing technologies only pay attention to the current shortest path. As resources on the shortest path are reserved, it will be necessary and viable to explore other paths in order to provide QoS to a flow.
研究と実用的な経験が最も短いベストエフォート型経路以上をサポートするのにIPでのQoSルーティングの領域で必要です、特にこの経路がATMネットワークを横断するとき。 多くのIPネットワークには、与えられたソースと目的地組の間には、複数の経路がありますが、現在のルーティング技術は現在の最短パスに注意を向けるだけです。 最短パスに関するリソースが予約されているので、他の経路を探検するのは、QoSを流れに提供するために必要であって、実行可能になるでしょう。
Enrichment of the ATM model to support dynamic QoS would greatly help the IP over ATM situation. At present, the QoS objectives for ATM are established at call set-up and then fixed for the duration of a call. It would be advantageous to have the ability to provide a dynamic QoS in ATM, so that an existing call could be modified to provide altered services.
ダイナミックなQoSをサポートするATMモデルの裕福はATM状況に関してIPを大いに助けるでしょう。 現在のところ、ATMのためのQoS目的のために呼び出しセットアップで確立されて、次に、呼び出しの持続時間は修理されています。 ダイナミックなQoSをATMに供給する能力を持っているのは有利でしょう、変えられたサービスを提供するように既存の呼び出しを変更できるように。
Another possible area of enhancement to the ATM service model is in the area of multicasting. The multicast QoS offered is equal for all receivers, and thus may be determined by the least favorable path through the tree or by the most demanding receiver. Furthermore, there is no current provision for multipoint to multipoint connections. This limitation may rule out some of the services envisioned in the IP service model.
ATMサービスモデルへの増進の別の可能な領域はマルチキャスティングの領域にあります。 QoSが提供したマルチキャストは、すべての受信機に等しく、その結果、木を通した、または、最も過酷な受信機による最も好ましくない経路のそばで決定しているかもしれません。その上、マルチポイント接続への多点へのどんな現在の支給もありません。 この制限はIPサービスモデルで思い描かれたサービスのいくつかを除外するかもしれません。
There are areas of potential enrichment of the IP model as well. While the receiver-based approach of RSVP has nice scaling properties and handles receiver heterogeneity well, it is not clear that it is ideal for all applications or for establishing state in ATM networks. It is possible that a sender-oriented mode for RSVP might ease the IP/ATM integration task.
また、IPモデルの潜在的裕福の領域があります。 RSVPの受信機ベースのアプローチは、良いスケーリング特性を持って、受信機の異種性をよく扱いますが、すべてのアプリケーションかATMネットワークに状態を設置するのに、それが理想的であることは、明確ではありません。 RSVPのための送付者指向のモードがIP/ATM統合タスクを緩和するのは、可能です。
Since the widespread availability of QoS raises new security concerns (e.g., denial of service by excessive resource reservation), it seems prudent that the IP and ATM communities work closely to adopt compatible approaches to handling these issues.
QoSの広範囲の有用性が新しい安全上の配慮(例えば、過度の資源予約によるサービスの否定)を上げるので、IPとATM共同体がこれらの問題を扱うことへのコンパチブルアプローチを取るために緊密に働いているのは慎重に思えます。
This list is almost certainly incomplete. As work progresses to define IP over ATM standards to support QoS and to implement integrated services internetworks that include ATM, more issues are likely to arise. However, we believe that this paper has described the major issues that need to be taken into consideration at this time by those who are defining the standards and building implementations.
このリストはほぼ確実に不完全です。 仕事がQoSをサポートして、統合サービスがATMを含んでいるインターネットワークであると実装するためにATM規格の上でIPを定義するために進歩をするとき、より多くの問題が起こりそうです。 しかしながら、私たちは、この論文がこのとき規格を定義して、実装を築き上げている人によって考慮に入れられる必要がある大変な問題について説明したと信じています。
Borden, et al Informational [Page 21] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[21ページ]RFC1821レアル-時間Service
9.0 References
9.0の参照箇所
1. Armitage, G., "Support for Multicast over UNI 3.1 based ATM
Networks", Work in Progress, Bellcore, February 1995.
1. アーミテージ、G.、「UNI3.1の上のMulticastのサポートはATM Networksを基礎づけた」Progress、Bellcore、1995年2月のWork。
2. Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, NRL, August 1995.
2. アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、NRL、1995年8月。
3. Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
3. アトキンソン、R.、「IP認証ヘッダー」、RFC1826、NRL、1995年8月。
4. Ballardie, A., and J. Crowcroft, "Multicast-Specific Security
Threats and Counter-Measures", Proceedings of ISOC Symposium on
Network and Distributed System Security, San Diego, Feb. 1995,
pp. 2-16.
4. NetworkとDistributed System Securityの上のISOC SymposiumのProceedings、サンディエゴ1995年2月のBallardie、A.、J.クロウクロフト、および「マルチキャスト特有の軍事的脅威と対応策」、ページ 2-16.
5. Ballardie, T., Jain, N., Reeve, S. "Core Based Trees (CBT)
Multicast, Protocol Specification", Work In Progress, University
College London, Bay Networks, June, 1995.
5. Ballardie、T.、ジャイナ教徒、N.、S. 「コアは木(CBT)のマルチキャストを基礎づけました、プロトコル仕様」という奉行は進行中(ユニバーシティ・カレッジロンドン、ベイネットワークス1995年6月)で働いています。
6. Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, ISI/MIT/Xerox
PARC, July 1994.
6. ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、ISI/MIT/ゼロックスPARC、1994年7月。
7. Braden, R., Zhang, L., Estrin, Herzog, D., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", Work in Progress, ISI/PARC/UCS, July 1995.
7. ブレーデン、R.、チャン、L.、Estrin、ハーツォグ、D.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、処理中の作業、ISI/PARC/UCS、1995年7月。
8. Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB
Workshop on Security in the Internet Architecture", RFC 1636, ISI,
MIT, TIS, INRIA, June 1994.
8. ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitema、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップのレポート」、RFC1636、ISI、MIT、TIS、INRIA(1994年6月)。
9. Callon, R., and B. Salkewicz, An Outline for Integrated PNNI for
IP Routing", ATM Forum/ 95-0649, Bay Networks, July 1995.
9. 「IPルート設定のための統合PNNIのためのCallon、R.、およびB.Salkewicz、アウトライン」、気圧フォーラム/95-0649、ベイネットワークス、7月1995
10. Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework
Document", Work in Progress, AT&T Bell Laboratories/ ANS, April
1995.
10. コール、R.、シュル、D.、およびC.Villamizar、「気圧でのIP:」 「フレームワークドキュメント」、進行中の仕事、AT&Tベル研究所/ANS、1995年4月。
11. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, Stanford University, August 1989.
11. デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
12. Delgrossi, L., and L. Berger, Editors, "Internet Stream Protocol
Version 2 (ST-2) Protocol Specification - Version ST2+", RFC 1819,
ST2 Working Group, August 1995.
12. Delgrossi、L.とL.バーガー、エディターズ、「インターネットストリームプロトコルバージョン2、(-2番目、)、仕様--バージョンについて議定書の中で述べてください、ST2+、」、RFC1819、ST2作業部会(1995年8月)
13. Dykeman, D., Ed., "PNNI Draft Specification", ATM Forum/94-0471R8,
IBM Zurich Research Lab, May 1995.
13. Dykeman、D.、エド、「PNNI草稿仕様」(気圧フォーラム/94-0471R8、IBMチューリッヒ研究研究室)は1995にそうするかもしれません。
Borden, et al Informational [Page 22] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[22ページ]RFC1821レアル-時間Service
14. Goyal, P., Lam, S., and Vin, H., "Determining End-to-End Delay
Bounds in Heterogeneous Networks," 5th International Workshop on
Network and Operating System Support for Digital Audio and Video,
April, 1995.(Available via URL http://www.cs.utexas.edu/users/dmcl)
14. GoyalとP.とラム、S.とヴィンとH.と「異機種ネットワークで終わりから端への遅れ領域を決定し」て、ネットワークに関する第5国際ワークショップとデジタル・オーディオとビデオのオペレーティングシステムサポート、1995年4月。(URL http://www.cs.utexas.edu/users/dmcl を通して利用可能)です。
15. Laubach, M., "Classical IP and ARP over ATM", RFC 1577, HP,
January 1994.
15. Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、hp、1月1994日
16. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.
16. Moy、J.、「OSPF、バージョン2インチ、RFC1583、Proteon、1994インチ年3月。
17. Moy, J., "Multicast Extensions to OSPF," RFC 1584, Proteon, March
1994.
17. Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、Proteon、1994年3月。
18. Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN,
September 1992.
18. ヤマウズラ、C.、「提案された流れ仕様」、RFC1363、BBN、1992年9月。
19. Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
ISI, Fore, Motorola Codex, Ascom Timeplex, February 1995.
19. ペレスとM.とLiawとF.とマンキンとA.とホフマンとE.とグロースマンとD.とA.Malis、「気圧でのIPの気圧シグナリングサポート」、RFC1755、ISI、前面、モトローラ古写本、Ascom Timeplex(1995年2月)。
20. Perkins, D., and Liaw, Fong-Ching, "Beyond Classical IP-Integrated
IP and ATM Architecture Overview", ATM Forum/94-0935, Fore Systems,
September 1994.
20. そして、パーキンス、D.とLiaw、フォン-チン、「古典的なIPが統合しているIP、気圧アーキテクチャ概要、」、気圧フォーラム/94-0935、前面のシステム、9月1994
21. Perkins, D. and Liaw, Fong-Ching, "Beyond Classical IP-Integrated
IP and ATM Protocol Specifications", ATM Forum/94-0936, Fore
Systems, September 1994.
21. パーキンスとD.とLiaw、フォン-チン、「古典的を超えて、IPはIP統合されていました、そして、気圧は仕様を議定書の中で述べる」気圧フォーラム/94-0936、前面のシステム、1994年9月。
22. Romanow, A., and S. Floyd, "The Dynamics of TCP Traffic over ATM
Networks", Proceedings of ACM SIGCOMM U94, London, August 1994,
pp.79-88.
22. Romanow、A.、およびS.フロイド、「気圧ネットワークの上のTCPトラフィックの力学」、ACM SIGCOMM U94のProceedings、ロンドン1994年8月(pp.79-88)。
23. Shenker, S., and C. Partridge. "Specification of Guaranteed Quality
of Service", Work in Progress, Xerox/BBN, July 1995.
23. Shenker、S.、およびC.ヤマウズラ。 「保証されたサービスの質の仕様」、処理中の作業、ゼロックス/BBN、1995年7月。
24. Shenker, S., and C. Partridge. "Specification of Predictive Quality
of Service", Work in Progress, Xerox/BBN, March 1995.
24. Shenker、S.、およびC.ヤマウズラ。 「予言のサービスの質の仕様」、処理中の作業、ゼロックス/BBN、1995年3月。
25. Shenker, S., C. Partridge and J. Wroclawski. "Specification of
Controlled Delay Quality of Service", Work in Progress,
Xerox/BBN/MIT, June 1995.
25. Shenker、S.、C.ヤマウズラ、およびJ.Wroclawski。 「制御遅れサービスの質の仕様」、処理中の作業、ゼロックス/BBN/MIT、1995年6月。
26. Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP:
A Transport Protocol for Real-time Applications", Work in Progress,
GMD/ISI/Xerox/LBL, March 1995.
26. Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、処理中の作業、GMD/ISI/ゼロックス/LBL、1995年3月。
27. Topolcic, C., "Experimental Internet Stream Protocol, Version 2
(ST-II)", RFC 1190, BBN, October 1990.
27. Topolcic、C.、「実験インターネットストリームプロトコル、バージョン2、(第-、II、)、」、RFC1190、BBN、10月1990日
Borden, et al Informational [Page 23] RFC 1821 Real-time Service in IP-ATM Networks August 1995
ボーデン、1995年のIP-ATM Networks8月の他のInformational[23ページ]RFC1821レアル-時間Service
28. Wang, Z., and J. Crowcroft, "QoS Routing for Supporting Resource
Reservation", University College of London white paper, 1995.
28. ワング、Z.、およびJ.クロウクロフト、「資源予約をサポートするためのQoSルート設定」、ロンドンユニバーシティ・カレッジは紙、1995を空白にします。
10. Authors' Addresses
10. 作者のアドレス
Eric S. Crawley Marty Borden Bay Networks 3 Federal Street Billerica, Ma 01821 508-670-8888 esc@baynetworks.com mborden@baynetworks.com
エリックS.クローリーマーティボーデンベイネットワークス3の連邦政府の通りビルリカ、マ01821 508-670-8888 esc@baynetworks.com mborden@baynetworks.com
Bruce S. Davie Bellcore 445 South Street Morristown, New Jersey 07960-6438 201-829-4838 bsd@bellcore.com
ブルースS.デイビーBellcore445南通りモリスタウン、ニュージャージー07960-6438 201-829-4838 bsd@bellcore.com
Stephen G. Batsell Naval Research Laboratory Code 5521 Washington, DC 20375-5337 202-767-3834 sgb@saturn.nrl.navy.mil
スティーブンG.Batsell海軍研究試験所コード5521ワシントン、DC20375-5337 202-767-3834 sgb@saturn.nrl.navy.mil
Borden, et al Informational [Page 24]
ボーデン、他のInformational[24ページ]
一覧
スポンサーリンク
