RFC1453 日本語訳
1453 A Comment on Packet Video Remote Conferencing and theTransport/Network Layers. W. Chimiak. April 1993. (Format: TXT=23563 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Chimiak
Request for Comments: 1453 BGSM
April 1993
Chimiakがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1453 BGSM1993年4月
A Comment on Packet Video Remote Conferencing and the
Transport/Network Layers
パケットのビデオのリモート会議のコメントと輸送/ネットワーク層
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
The new generation of multimedia applications demands new features and new mechanisms for proper performance. ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user. In an effort to anticipate the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT [RFC 988], and VMTP [RFC 1045] were developed. The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of Xpress Transfer Protocol (XTP) [XTP92] with the goal of eventually delivering ATM bandwidths to a user process. This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind.
マルチメディア応用の新しい世代は相当の行為について新機能と新しいメカニズムを要求します。 ATM技術は概念から現実まで移行しました、まさしくその高帯域と新しい能力をデータ・リンク層ユーザに提供して。 予期する取り組みでは、高帯域遅れデータ・リンク層、デルタ-t[デルタ-t]、NETBLT[RFC988]、およびVMTP[RFC1045]は開発されました。 これらの実験インターネットプロトコルのクリエイターによって開拓された素晴らしい洞察とメカニズムはユーザ・プロセスへの帯域幅をATMに提供する結局の目標でエクスプレスTransferプロトコル(XTP)[XTP92]のデザインに使用されました。 このRFCは現れているATMネットワークと共にインターネット活動と目標の先で汎用アプリケーションとマルチメディア応用の念頭に利益を得るときXTPに関してインターネットコミュニティを知らせる乗り物です。
1. Introduction
1. 序論
Networking is no longer synonymous with analog telephony. High- performance lower-layer networks have made possible exciting new applications: collaboratory environments, distributed client/server computing, remote conferencing, teleclassrooms, and distributed life-sciences imaging. These applications normally demand a great deal of bandwidth and often create operating system bottlenecks. Enabling these new multimedia applications entails delivering bandwidth to the applications, not just having bandwidth available on the network. This statement may appear obvious, but often solutions at the transport layer are satisfied by having bandwidth at that layer without sufficient sensitivity to higher-layer access to the bandwidth. The unavailability of bandwidth at upper layers is becoming the real issue as the networks are becoming a high- performance virtual backplane without concomitant high-performance control schemes. It appears that new services are needed that require communication with all layers. The ATM architecture calls
ネットワークはもうアナログの電話と同義ではありません。 高い性能下層ネットワークは可能なおもしろい新しいアプリケーションをしました: 分配されたcollaboratory環境、サーバコンピューティング、リモート会議、teleclassrooms、および分配されたクライアント/生命科学イメージ。 これらのアプリケーションは、通常、多くの帯域幅を要求して、しばしばオペレーティングシステムボトルネックを作成します。 これらの新しいマルチメディア応用を可能にするのは、ただネットワークで利用可能な帯域幅を持っているのではなく、帯域幅をアプリケーションに提供するのを伴います。 この声明は明白に見えるかもしれませんが、しばしば、トランスポート層のソリューションは、その層に十分な感度なしで帯域幅への、より高い層のアクセスに帯域幅を持っていることによって、満たされています。 ネットワークが並立している高性能コントロール体系なしで高い性能仮想のバックプレーンになっているとき、上側の層の帯域幅の使用不能は実際の問題になっています。 すべての層とのコミュニケーションを必要とする新種業務が必要であるように見えます。 ATMアーキテクチャは呼びます。
Chimiak [Page 1] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[1ページ]RFC1453は1993年4月にビデオ会議を批評します。
for such an integrated control scheme.
そのような総合防除を、計画してください。
2. Remote Conferencing
2. リモート会議
The challenges of remote conferencing is an application whose challenges may be met at the data link layer by the emerging broadband networks. If so, important medical applications such as medical imaging for diagnosis and treatment planning would be possible [CHIM92]. Remote conferencing would permit imaging applications for life sciences through the use of national resource centers. Collaboratory conferences in molecular modeling, design efforts, and visualization of data in numerous disciplines could become possible.
リモート会議の挑戦は挑戦が現れている広帯域ネットワークによってデータ・リンク層で迎えられるかもしれないアプリケーションです。 そうだとすれば、診療計画のための医療画像処理などの重要な医療のアプリケーションは可能でしょう[CHIM92]。 リモート会議は、国家のリソースセンターの使用で生命科学のアプリケーションに像を描くことを許可するでしょう。 多数の規律における、データの分子モデル、デザイン取り組み、および想像におけるCollaboratory会議は可能になることができました。
At the Second Packet Video Workshop, held December, 1992, at MCNC in the Research Triangle Park, North Carolina, a recurrent theme was the use of multimedia in remote conferencing. Its applications included the use of interactive, synchronized voice and video transmission, multicast transmission, data transfer, graphics transmission, noninteractive video and audio transmission, and data base query within a virtually shared workspace. A few participants doubted the ability of current computer networks to handle these multimedia applications and preferred only connection-oriented, circuit-switched services. Most participants, however, looked forward to using an integrated network approach.
1992年12月にリサーチトライアングルPark、ノースカロライナのMCNCで持たれていたSecond Packet Video Workshopでは、繰り返し現れる主題はリモート会議でマルチメディアの使用でした。 アプリケーションは実際には共有されたワークスペースの中にインタラクティブの使用、連動している声、映像の送波、マルチキャスト送信、データ転送、グラフィックス送信、非対話的なビデオ、音声通信、およびデータベース質問を含んでいました。 数人の関係者が、現在のコンピュータネットワークがこれらのマルチメディア応用を扱う能力を疑って、接続指向の、そして、回路で切り換えられたサービスだけを好みました。 しかしながら、ほとんどの関係者が、統合ネットワークアプローチを使用するのを楽しみにしていました。
2.1. Remote Conferencing Functions and Requirements
2.1. リモート会議機能と要件
Remote conferencing as seen at the workshop requires a set of functions. It must provide session scheduling that deals with initiating a session, joining in-progress sessions, leaving a session without tearing it down if there are multiple participants, and terminating a session.
ワークショップで見られるリモート会議は関数群を必要とします。 それはそれが複数の関係者がいればそれを取りこわして、終わらないでセッションを残して、進行中のセッションに参加して、セッションを開始しながら対処するセッションスケジューリングにセッションを提供しなければなりません。
The remote-conferencing session needs a control subsystem that is either tightly controlled for an n-to-n connection for two to 15 participants, or loosely controlled for a 1-to-n connection for any number of participants. The Multipeer-Multicast Consortium is working on defining the control requirements and the mechanisms for control. At the Packet Video Workshop, one participant presented a conference control protocol (CCP) shown in Figure 1 [CCP92]. In this architecture the CCP controls the Network Voice Protocol (NVP) [RFC741] and the Packet Video Protocol (PVP) [PVP81] over the experimental Internet Stream Protocol, Version 2 (ST-II) [RFC1190] rather than IP.
リモート会議セッションは2〜15人の関係者のためのnからnとの接続のためにしっかり制御されるか、またはいろいろな関係者のためのnへの1つの接続のために緩く制御されるコントロールサブシステムを必要とします。 Multipeer-マルチキャストConsortiumはコントロールのためにコントロール要件とメカニズムを定義するのに働いています。 Packet Video Workshopでは、1人の関係者が図1[CCP92]に示された会議制御プロトコル(CCP)を提示しました。 このアーキテクチャでは、CCPは実験インターネットStreamプロトコルIPよりむしろバージョン2(ST-II)[RFC1190]の上でNetwork Voiceプロトコル(NVP)[RFC741]とPacket Videoプロトコル(PVP)[PVP81]を制御します。
Latency and intramedia synchronization and intermedia synchronization (lip-sync) are critical for the interactive voice and video streams
対話的な声とビデオストリームに、潜在、intramedia同期、および中間体同期(口パク)は重要です。
Chimiak [Page 2] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[2ページ]RFC1453は1993年4月にビデオ会議を批評します。
of remote conferencing. Client/server applications including data base operations are equally important. The ability to display noninteractive video and high-resolution graphics is necessary.
リモート会議について。 データベース操作を含むクライアント/サーバ・アプリケーションは等しく重要です。 非対話的なビデオと高画質グラフィックスを表示する能力が必要です。
As with most applications, security will eventually be an issue. At the very least, there must be a mechanism to determine who can find out what about conference and who can join a conference. This determination will be part of an upper-layer protocol.
ほとんどのアプリケーションの場合、セキュリティは結局、問題になるでしょう。 少なくとも、だれが、会議と会議に参加できるかをどうである見つけることができるかを決定するメカニズムがあるに違いありません。 この決断は上側の層のプロトコルの一部になるでしょう。
+--------------+ +--------+ +-----+ +------------+
|Teleconference| | File | |Email| | Domain |
| (CCP) | |Transfer| | | |Name Service|
+----+-------+-+ +-----+--+ +-+---+ +-----+------+
| | |__ __| |
| | || |
+-----+--+ +--+-----+ +-++-+ +----+---+
|Network | | Packet | | T | | U |
| Voice | | Video | | C | | D |
|Protocol| |Protocol| | P | | P |
+---+----+ +--+-----+ +-+--+ +--+-----+
|__ __| |__ __|
| | | |
+-+---+--+ +-+-------+-+
| Stream | | I |
|Protocol| | P |
+---+----+ +---+-------+
| |
+-----+----------------------+----+
|IEEE_802.X,FDDI,DARTnet,ATOMIC...|
+---------------------------------+
+--------------+ +--------+ +-----+ +------------+ |電子会議| | ファイル| |メール| | ドメイン| | (CCP) | |転送| | | |名前サービス| +----+-------+-+ +-----+--+ +-+---+ +-----+------+ | | |__ __| | | | || | +-----+--+ +--+-----+ +-++-+ +----+---+ |ネットワーク| | パケット| | T| | U| | 声| | ビデオ| | C| | D| |プロトコル| |プロトコル| | P| | P| +---+----+ +--+-----+ +-+--+ +--+-----+ |__ __| |__ __| | | | | +-+---+--+ +-+-------+-+ | ストリーム| | I| |プロトコル| | P| +---+----+ +---+-------+ | | +-----+----------------------+----+ |IEEE_802.X、DARTnetの、そして、原子のFDDI…| +---------------------------------+
Figure 1: The Connection Control Protocol Architecture
図1: 接続制御プロトコルアーキテクチャ
The solutions must range in geography from single machines through LAN, CAN, MAN, WAN conferences, as well as in data content from PCs to high-end workstations. Implicit in the scaling is the notion of product and application interoperability.
ソリューションは単一マシンからLANまで地理学のねらいを定めなければなりません、CAN、MAN、WAN会議、データがPCからハイエンドワークステーションまで満足させるコネと同様に。 スケーリングで暗黙であることは、製品とアプリケーション相互運用性の概念です。
Remote conferencing applications should take advantage of future network enhancements, as well as the functions provided by ATM, FDDI, and SMDS. Doing so should provide function versus resource trade- offs such as cost versus error control and cost versus rate control. As a result, the transport layer should be able to provide the services offered by the data link layer.
リモート会議アプリケーションは今後のネットワーク増進を利用するべきです、ATM、FDDI、およびSMDSによって提供された機能と同様に。 そうするのは費用対誤り制御や費用などのリソース貿易offs対速度制御に機能を供給するべきです。 その結果、トランスポート層はデータ・リンク層によって提供されたサービスを提供するはずであることができます。
Most of the presentation on remote conferencing indicated a need for some degree of multicast functionality, ranging from the 1-to-n, with conference membership completely known, to conferences for which
リモート会議におけるプレゼンテーションの大部分はいくらかのマルチキャストの機能性の必要性を示しました、1〜nで及んで、会議会員資格が完全に知られている状態で、会議にどれ
Chimiak [Page 3] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[3ページ]RFC1453は1993年4月にビデオ会議を批評します。
existence of a group is known, but exact membership is not.
グループの存在は知られていますが、正確な会員資格は知られているというわけではありません。
In remote conferencing, it is preferable to use one network for all information traffic. This network should have an offered quality of service (QOS) criteria to accommodate tradeoff metrics, which would include guaranteed throughput, connection reliability, high call- completion rate, few dropped calls, tolerable error rate, varying degrees of compression on the video and audio streams, and tolerable motion artifacts, flow control, and latency. The QOS should be an input to the transport layer from the application or transport service user.
リモート会議では、すべての情報トラフィックに1つのネットワークを使用するのは望ましいです。 このネットワークには、保証されたスループット、接続の信頼性、高い呼び出し完成率、わずかな下げられた呼び出し、許容できる誤り率、ビデオにおける圧縮の異なった度合い、オーディオのストリーム、および許容できる動き人工物を含んでいるだろう見返り測定基準に対応するサービス(QOS)評価基準の提供された品質、フロー制御、および潜在があるべきです。 QOSはアプリケーションか輸送サービス利用者からのトランスポート層への入力であるべきです。
The compression/coding function should provide time-stamping and packetizing information, as well as real-time echo cancellation. These functions are usually at the presentation and session layer of the Open System Interconnection (OSI) model or the at the application in some Internet models, but not the transport layer.
圧縮/コード化機能はリアルタイムのエコーキャンセルと同様に情報を時間の刻印とpacketizingに提供するべきです。 または、通常オープンSystem Interconnection(OSI)モデルのプレゼンテーションとセッション層にはこれらの機能がある、輸送ではなく、何人かのインターネットモデルにおけるアプリケーションのときに、層にしてください。
3. Potential Solutions
3. 潜在的ソリューション
RFC 1193 deals with the requirements of real-time communications, which include some of the same capabilities [RFC1193]. But the requirements articulated create the necessity for new transport/network protocols. The new protocols under development by the Audio Visual Transport [SCHU92] (RTC, RTCP), and other protocols in this area (ST-II) suggest an architecture like that shown in Figure 2.
RFC1193は瞬時通信の要件に対処します。(瞬時通信は同じ能力[RFC1193]のいくつかを含んでいます)。 しかし、明確に話された要件は新しい輸送/ネットワーク・プロトコルの必要性を作成します。 この領域のAudio Visual Transport[SCHU92](RTC、RTCP)、および他のプロトコルによる開発中の新しいプロトコルは図2に示されたそのようなアーキテクチャを示します(ST-II)。
These approaches may work. However, they encourage a discipline that creates a protocol for each new class of application. Another approach might be to unify the protocols. It is felt that this is one of the main goals of XTP (see Figure 3).
これらのアプローチは働くかもしれません。 しかしながら、彼らはそれぞれの新しいクラスの適用のためにプロトコルを作成する規律を奨励します。 別のアプローチはプロトコルを統一することであるかもしれません。 これがXTPの第一目的の1つ(図3を見る)であると感じられます。
Other design considerations of XTP include the following:
XTPの他のデザイン問題は以下を含んでいます:
Chimiak [Page 4] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[4ページ]RFC1453は1993年4月にビデオ会議を批評します。
+----------------------+
| media |
| application |
+--------+----+-+------+
| |RTCP| | |
| +----+ | T |
| RTP | C |
+-----+-----+ | P |
|ST-II| UDP | | |
+ +-----+---+------|
| | IP |
+-----+-------+--------+
| Data Link Layer |
+----------------------+
+----------------------+ | メディア| | アプリケーション| +--------+----+-+------+ | |RTCP| | | | +----+ | T| | RTP| C| +-----+-----+ | P| |第-、II| UDP| | | + +-----+---+------| | | IP| +-----+-------+--------+ | データ・リンク層| +----------------------+
Figure 2: One emerging multimedia architecture
図2: 1つの現れているマルチメディアアーキテクチャ
+--------------+ +--------+ +-----+ +------------++-----------+
|Teleconference| | File | |Email| | Domain || media |
| | |Transfer| | | |Name Service||application|
+------+-------+ +----+---+ +--+--+ +-----+------++-----+-----+
| | | | |
+---------------+--------+----------+-------------+
|
+-------+--------+
|Unified Protocol|
+----------------+
|Data Link Layer |
+----------------+
+--------------+ +--------+ +-----+ +------------++-----------+ |電子会議| | ファイル| |メール| | ドメイン|| メディア| | | |転送| | | |名前サービス||アプリケーション| +------+-------+ +----+---+ +--+--+ +-----+------++-----+-----+ | | | | | +---------------+--------+----------+-------------+ | +-------+--------+ |統一されたプロトコル| +----------------+ |データ・リンク層| +----------------+
Figure 3: Another integrated multimedia architecture
図3: 別の統合マルチメディアアーキテクチャ
(1) Developing a protocol based on the work and experience of
the protocol groups such as IETF, which produced NETBLT,
VMTP, TCP, IP, and UDP.
(1) 仕事に基づくプロトコルとプロトコルの経験を開発するのはIETFなどのように分類されます。(IETFはNETBLT、VMTP、TCP、IP、およびUDPを生産しました)。
(2) Incorporating lessons from Delta-t.
(2) デルタ-tからレッスンを取り入れること。
(3) Observing the design paradigm shift of ATM, SONET, and VMTP
in the header, trailer, and information segment construction.
(3) ヘッダー、トレーラ、および情報セグメント構造でATM、Sonet、およびVMTPのデザインパラダイム・シフトを観測すること。
(4) Targeting the real-time requirements articulated by the
Department of Defense SAFENET committee and the French
Ministry of Defense military real-time specification [GAM-T-103].
(4) 国防総省SAFENET委員会とフランスの国防省軍事のリアルタイムの仕様[GAM-T-103]でリアルタイムの要件を狙うのは文節に分けられました。
Mechanisms in XTP allow an application to approach the performance desired. A session-scheduling mechanism for joining and leaving a
XTPのメカニズムは性能が望んでいたアプローチにアプリケーションを許容します。 aを接合して、残すためのセッションの計画ををするメカニズム
Chimiak [Page 5] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[5ページ]RFC1453は1993年4月にビデオ会議を批評します。
multicast conference exists. The XTP mechanism for multicast satisfies the loosely controlled session requirements. The tightly controlled session would require the use of multiple XTP associations.
マルチキャスト会議は存在します。 マルチキャストのためのXTPメカニズムは緩く制御されたセッション要件を満たします。 しっかり制御されたセッションは複数のXTP協会の使用を必要とするでしょう。
The priority mechanism that uses the 32-bit SORT field permits an application to prioritize data. Because XTP is a transport layer, this priority mechanism follows through every node tranversed. There is also an out-of-band delivery mechanism. However, XTP does not offer latency control by itself; it just provides a priority mechanism.
32ビットのSORT分野を使用する優先権メカニズムは、アプリケーションがデータを最優先させるのを可能にします。 XTPがトランスポート層であるので、この優先権メカニズムはtranversedされたあらゆるノードを通して従います。 また、バンドで出ている排紙機構があります。 しかしながら、XTP自身は潜在コントロールを提供しません。 それはただ優先権メカニズムを提供します。
The selective acknowledgement, fast negative acknowledgement, and selective retransmission permit an application to choose an appropriate level of error control. The combination of the priority mechanism and these error-control mechanisms is likely to approach the latency and synchronization requirements of remote conferencing.
選択している承認、速い否定的承認、および選択している「再-トランスミッション」は、アプリケーションが適正水準の誤り制御を選ぶのを可能にします。 優先権メカニズムとこれらの誤り制御メカニズムの組み合わせはリモート会議の潜在と同期要件にアプローチしそうです。
Noninteractive audio and video, as well as graphics presentation, can be accommodated in many ways by the application. It is important that the transport layer provides adequate mechanisms to deliver the appropriate data streams in a manner compatible with the applications. These applications can probably be accomplished by means of extant protocols, as well as XTP.
様々な意味でアプリケーションで非対話的なオーディオ、ビデオ、およびグラフィックスプレゼンテーションを設備することができます。 トランスポート層がアプリケーションとのコンパチブル方法で適切なデータ・ストリームを提供するために適切なメカニズムを提供するのは、重要です。 実在のプロトコル、およびXTPによってたぶんこれらのアプリケーションを実行できます。
The scalability of the solution will be a function of the standards used. At the Packet Video Workshop, some of the applications sacrificed computer network standards in favor of desired performance. This approach usually impedes scalability. From the explanation of the applications taking this approach, it appeared that using XTP would have provided an adequate transport service for the applications.
ソリューションのスケーラビリティは使用される規格の関数になるでしょう。 Packet Video Workshopでは、アプリケーションのいくつかが必要な性能を支持してコンピュータネットワーク規格を犠牲にしました。 通常、このアプローチはスケーラビリティを妨害します。 このアプローチを取るアプリケーションに関する説明から、XTPを使用するとアプリケーションのための適切な輸送サービスが提供されたように見えました。
XTP was designed to provide mechanisms to accommodate application requirements, that is, the ability to respond to QOS requests. For example, guaranteed throughput may be accomplished by using XTP's rate and burst control together with flow control or no flow control. Tolerable error rate can be accomplished with partially error controlled connections (PECC), a service which can be placed in the application or just above the transport layer [PECC92]. Motion artifacts and varying degrees of compression should be done above the transport layer in coordination with the transport layer or possibly in a network management function.
XTPは、アプリケーション要件、QOS要求に応じるすなわち、能力を収容するためにメカニズムを提供するように設計されました。 例えば、保証されたスループットは、フロー制御にもかかわらず、どんなフロー制御と共にもXTPのレートを使用することによって実行されて、コントロールを押し破かないかもしれません。 許容できる誤り率を達成できる、部分的に、誤りは接続(PECC)(アプリケーションか[PECC92]トランスポート層のすぐ上に置くことができるサービス)を監督しました。 トランスポート層を超えてトランスポート層によるコーディネートかことによるとネットワークマネージメント機能で動き人工物と異なった度合いの圧縮をするべきです。
3.1. Synthesize the Hardware Fabrication Process into the Design
3.1. ハードウェア製作過程をデザインに統合してください。
To produce an affordable solution, the hardware fabrication process should be a design consideration. Technologies are evolving too
手頃な解決策を作成するために、ハードウェア製作過程は設計の検討であるべきです。 また、技術は発展することです。
Chimiak [Page 6] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[6ページ]RFC1453は1993年4月にビデオ会議を批評します。
rapidly to assume that a generic protocol design will anticipate all fabrication advances, but this fact should not impede use of the features of advanced hardware fabrication processes.
急速に、ジェネリックプロトコルデザインがすべての製作を予期すると仮定するのを進みますが、この事実は高度なハードウェア製作過程の特徴の使用を妨害するべきではありません。
System interface problems and VLSI techniques should be considered in the specification of the protocol. An examination of the ATM and SONET standards appears to support this philosophy. Similarly, NETBLT and VMTP design efforts seem to support this approach. XTP does use it.
システム・インタフェース問題とVLSIのテクニックはプロトコルの仕様で考えられるべきです。 ATMとSonet規格の試験はこの哲学をサポートするように見えます。 同様に、NETBLTとVMTPデザイン取り組みはこのアプローチをサポートするように思えます。 XTPはそれを使用します。
It is very helpful to break down the protocol into parallel-state machines for execution on more inexpensive hardware. This procedure reduces the context switching and interrupt handling requirements of the hardware, thereby decreasing production costs while producing a scalable protocol machine.
より安価なハードウェアの上で実行のための平行な州のマシンにプロトコルを分解するのは非常に役立っています。 この手順はハードウェアのコンテキストスイッチと割込み処理要件を減らします、その結果、スケーラブルなプロトコルマシンを生産している間、生産費を減少させます。
4. Multimedia Applications over XTP
4. XTPの上のマルチメディア応用
In parallel with the IETF efforts to enable multimedia applications such as remote conferencing, the XTP forum members have been experimenting with major elements of these applications.
リモート会議などのマルチメディア応用を可能にするIETF取り組みと平行して、XTPフォーラムメンバーはこれらのアプリケーションの多量栄養素を実験しています。
(1) At the University of Virginia, more than 100 simulated voice
channels were run on an FDDI network [UVAVOICE92]. The
purpose of this experiment was to test the limits of FDDI
and a software version of XTP in a simulated interactive
voice environment. Multicasted, noninteractive video has
been supported there for several years.
(1) バージニア大学では、100個以上のシミュレートされた音声チャンネルがFDDIネットワーク[UVAVOICE92]で車で送られました。 この実験の目的はシミュレートされた対話的な声の環境でFDDIの限界とXTPのソフトウェアバージョンをテストすることでした。 Multicastedされて、非対話的なビデオは数年間そこで支えられています。
UVa also has a video-mail demo over XTP/FDDI that uses
Fluent multimedia interface and standard JPEG compression.
This PC-based demo delivers full frame, full color, 30
frames/sec video from any network disk to a remote VGA
screen. It is important that users could not discern any
difference in playback between a local disk and a remote
disk. An Xpress File System (XFS) is used on server and
client systems.
また、UVaには、Fluentマルチメディアインタフェースと標準のJPEG圧縮を使用するXTP/FDDIの上のビデオメールデモがあります。 このPCベースのデモはどんなネットワークディスクからリモートVGAスクリーンまでも完全なフレーム、フルカラー、30フレーム/秒のビデオを提供します。 ユーザがローカルディスクとリモートディスクの間で再生で少しの違いについても明察できなかったのは、重要です。 エクスプレスFile System(XFS)はサーバとクライアントシステムの上で使用されます。
(2) The Technical University of Berlin, Germany, reports that
the coordination, implementation, and operation of
multimedia services (CIO) of the R&D in Advanced
Communications Technologies in Europe (RACE) is using XTP as
a starting point for design [XTPRACE].
(2) ベルリン(ドイツ)のTechnical大学は、ヨーロッパ(RACE)のAdvanced Communications Technologiesでの研究開発のマルチメディアサービス(CIO)のコーディネート、実装、および操作がデザイン[XTPRACE]に出発点としてXTPを使用していると報告します。
(3) At the Naval Command, Control, and Ocean Surveillance Center
Research, Development, Test and Evaluation Division NRaD
(formerly the Naval Ocean Systems Command (NOSC)), voice is
(3)、Naval Command、ControlとOcean SurveillanceセンターResearchとDevelopmentとTestとEvaluation事業部NRaD(以前Naval Ocean Systems Command(NOSC))、声はそうです。
Chimiak [Page 7] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[7ページ]RFC1453は1993年4月にビデオ会議を批評します。
multicasted over XTP/FDDI. A simple multicast is
distributed to a group with a latency of around 25 ms, where
the latency represents delay from the voice signal from the
microphone to the audio signal to the speaker. This group
is currently doing research on an n-party multicast of voice
(telephone conference-call paradigm [n x n multicast]).
XTP/FDDIの上でmulticastedしました。 簡単なマルチキャストは潜在が音声信号から遅れをスピーカーにマイクロホンから音声信号まで表すおよそ25msの潜在があるグループに分配されます。 現在、このグループは声(電話電話会議パラダイム[n x nマルチキャスト])のn-パーティーマルチキャストのする研究です。
(4) Commercially, Starlight Networks Inc., migrated a subset of
XTP into the transport layer of its video application
server. By using XTP rate control, full-motion, full-screen
compressed video is delivered at a constant 1.2 Mbps, over
switched-hub Ethernet to viewstations. This network
delivers at least 10 simultaneous video streams.
(4) Starlight Networks Inc.(ビデオアプリケーション・サーバーのトランスポート層の中へのXTPの移行したa部分集合)がXTP速度制御を使用して、商業的に完全な動きです、フルスクリーンの圧縮されたビデオは一定の1.2Mbpsで提供されます、viewstationsへの切り換えられたハブイーサネットの上で。 このネットワークは少なくとも10の同時のビデオストリームを提供します。
Therefore, XTP has been used in applications that were previously placed over IP or even a data link layer.
したがって、XTPは以前にIPの上に置かれたアプリケーションかデータ・リンク層にさえ使用されました。
5. Policy versus Mechanism
5. 方針対メカニズム
Separating protocol policies and mechanisms [XTPbk] permits adoption of new policies without altering offered mechanisms. An excellent example is UVa's Partially Error Controlled Connections (PECC). This control system maximizes error control in such a way that receiving FIFOs are never starved i.e., the application, driver, or operating system buffer control, and not the transport layer becomes the bottleneck.
提供されたメカニズムを変更しないで、プロトコル方針とメカニズム[XTPbk]を切り離すと、新しい政策の採用は可能にします。好例はUVaのPartially Error Controlledコネクションズ(PECC)です。 この制御システムは受信先入れ先出し法が決して飢えていないような方法で誤り制御を最大にします、すなわち、トランスポート層ではなく、アプリケーション、ドライバー、またはオペレーティングシステムバッファ管理がボトルネックになります。
Because XTP is mechanism-rich and policy-tolerant, this very dynamic error control policy mechanism is possible. Separating policy and mechanism permits an error-control or flow-control policy to adapt to the data link layer conditions without shutting down a connection and rebuilding (or multiplexing) a new one on a different protocol stack. This may also provide an easier way for a network management subsystem to maintain a desired QOS.
XTPはメカニズム豊富であって、方針許容性があるので、この非常にダイナミックな誤り制御方針メカニズムは可能です。 方針とメカニズムを切り離すのは、誤り制御かフロー制御方針が異なったプロトコル・スタックに接続を止めて、新しいものを再建しないで(または、多重送信します)データ・リンク層状態に順応することを許可します。 また、これはネットワークマネージメントサブシステムが必要なQOSを維持する近道を提供するかもしれません。
6. Summary
6. 概要
Remote conferencing presents new opportunities for research, business, and administration. Although some are proposing that only classical circuit-switched mechanisms be used, most network engineers are searching for ways to use the new features of FDDI, SMDS, and ATM in multimedia applications such as remote conferencing. Some new applications have been placed directly on a data link layer. New Transport/Network layer combinations have been proposed and are being tested. It is believed that consideration should be given to XTP as a possible solution because its forum membership includes commercial, government, and research institutions, some of which have implemented various applications that contribute to an overall remote-
リモート会議は研究、ビジネス、および管理の新しい機会を提示します。 或るものは、古典的な回路で切り換えられたメカニズムだけが使用されるよう提案していますが、ほとんどのネットワーク・デザイナーがリモート会議などのマルチメディア応用でFDDI、SMDS、およびATMに関する新機能を使用する方法を捜し求めています。 いくつかの新しいアプリケーションが直接データ・リンク層に置かれました。 新しいTransport/ネットワーク層組み合わせは、提案されて、テストされています。 フォーラム会員資格がコマーシャル、政府、および研究所を含んでいるので考慮が可能なソリューションとしてXTPに対して払われるべきであると信じられている、総合的である、リモート。それの或るものは研究所のためにそれが貢献する様々なアプリケーションを実装しました。
Chimiak [Page 8] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[8ページ]RFC1453は1993年4月にビデオ会議を批評します。
conferencing application.
会議アプリケーション。
7. References
7. 参照
[CCP92] Schooler, E., "An Architecture for Multimedia Connection
Management", in Proceedings of the 4th IEEE ComSoc
International Workshop on Multimedia Communications,
Monterey, CA, April 1992.
[CCP92]の学生、E.、マルチメディア通信(モントレー(カリフォルニア)1992年4月)における第4IEEE ComSocの国際ワークショップの議事における「マルチメディア接続管理のためのアーキテクチャ。」
[CHIM92] Chimiak, W., "The Digital Radiology Environment", IEEE
JSAC, Vol. 10, No. 7, pp. 1133-1144, September 1992.
[CHIM92] Chimiak、W.、「デジタル放射線学環境」、IEEE JSAC、Vol.10、No.7、ページ 1133-1144と、1992年9月。
[Delta-t] Watson, R. W., "Delta-t Protocols Specification",
Lawrence Livermore Laboratory, April 15, 1983.
[デルタ-t] ワトソン、R.W.、「デルタ-tプロトコル仕様」、ローレンスリバーモア研究所、1983年4月15日。
[GAM-T-103] French Ministry of Defense, "GAM-T-103 Military
Real-Time Local Area Network Reference Model
(Transfer Layer)", February 7, 1987.
[GAM-T-103]フランスの国防省、「GAM-T-103軍用のリアルタイムのローカル・エリア・ネットワーク規範モデル(転送層)」、1987年2月7日。
[PECC92] Dempsey, B., Strayer, T. and Weaver A., "Adaptive Error
Control for Multimedia Data Transfer", in Proceedings
of the IWACA 92, Munich, Germany, pp. 279-288, March
1992.
IWACA92、ミュンヘン(ドイツ)のページのProceedingsの[PECC92]デンプシーとB.とStrayerとT.とウィーバーA.、「マルチメディアデータ転送のための適応型の誤り制御」 279-288と、1992年3月。
[PVP81] Cole, R., "PVP - A Packet Video Protocol", W-Note 28,
Information Sciences institute, University of
California, Los Angeles, CA, August 1981.
28、Sciencesが設ける情報、カリフォルニア大学ロサンゼルス校、カリフォルニア(1981年8月)は、[PVP81]コール、R.、「PVP--パケットビデオは議定書を作る」とWで述べます。
[RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol Specification", RFC 1045, Stanford
University, February 1988.
[RFC1045]Cheriton、D.、「VMTP:」 「多能なメッセージトランザクションプロトコル仕様」、RFC1045、スタンフォード大学、1988年2月。
[RFC998] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
Data Transfer Protocol", RFC 998, MIT, March 1987.
[RFC998] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[RFC1193] Ferrari, D., "Client Requirements For Real-Time
Communication Services", RFC 1193, UC Berkeley,
November 1990.
[RFC1193]フェラーリ、D.、「リアルタイムの通信サービスのためのクライアント要件」、RFC1193、UCバークレー1990年11月。
[RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
Protocol: Version 2 (ST-II)", RFC 1190, CIP Working
Group, October 1990.
[RFC1190] Topolcic、C.、エディタ、「実験的なインターネットはプロトコルを流します」。 「バージョン2、(第-、II、)、」、RFC1190、CIP作業部会、10月1990
[SCHU92] Schulzrinne, H., "A Transport Protocol for Audio and
Video Conferences and other Multiparticipant
Real-Time Applications", Internet Engineering Task
Force, Internet-Draft, October 1992.
[SCHU92] Schulzrinne、「AudioのためのTransportプロトコルとVideoコンファレンスと他のMultiparticipantレアル-時間Applications」(インターネット・エンジニアリング・タスク・フォース)が1992年10月にインターネットで作成するH.。
Chimiak [Page 9] RFC 1453 Comments on Video Conferencing April 1993
Chimiak[9ページ]RFC1453は1993年4月にビデオ会議を批評します。
[UVAVOICE92] Weaver, A. C. and McNabb, J.F., "Digitized Voice
Distribution Using XTP and FDDI", Transfer, Vol. 5,
No. 6, pp. 2-7 (November/December 1992).
[UVAVOICE92]ウィーバーとA.C.とマックナブ、J.F.、「XTPとFDDIを使用するデジタル化している声の分配」、Transfer、Vol.5、No.6、ページ 2-7 (1992年11月/12月。)
[XTP92] Xpress Transfer Protocol, version 3.6, XTP Forum,
1900 State Street, Suite D, Santa Barbara, California
93101 USA, January 11, 1992.
[XTP92] エクスプレスTransferプロトコル、バージョン3.6、XTP Forum、1900年のステイト・ストリート、Suite D、サンタバーバラ、1992年1月11日のカリフォルニア93101米国。
[XTPbk] Strayer, W.T., Dempsey, B.J., and Weaver, A.C., "XTP:
The Xpress Transfer Protocol", Addison-Wesley
Publishing Company, Inc., 1992.
[XTPbk]迷い人とW.T.とデンプシー、B.J.とウィーバー、西暦、「XTP:」 アディソン-ウエスリーは会社Inc.、1992を発行して「エクスプレスはプロトコルを移す」。
[XTPRACE] Rebensburg, K. and Miloucheva, I., "The Use of XTP in a
Large European Communication Project", XTP Forum
Research Affiliate Annual Report, Document 92-183,
pp. 105-112, 1992.
[XTPRACE] RebensburgとK.とMiloucheva、I.、「大きいヨーロッパのコミュニケーションプロジェクトにおけるXTPの使用」、XTP Forum Research Affiliate Annual Report、Document92-183、ページ 105-112, 1992.
Security Considerations
セキュリティ問題
Security issues are discussed in section 2.1.
セクション2.1で安全保障問題について議論します。
Author's Address
作者のアドレス
William J. Chimiak Department of Radiology Bowman Gray School of Medicine Medical Center Boulevard Winston-Salem, NC 27157-1022
ウィリアム・J.Chimiak放射線科射手のグレー・医科大学メディカル・センターBoulevardウィンストンセイレム、NC27157-1022
Phone: 919-716-2815 EMail: chim@relito.medeng.wfu.edu
以下に電話をしてください。 919-716-2815 メールしてください: chim@relito.medeng.wfu.edu
Chimiak [Page 10]
Chimiak[10ページ]
一覧
スポンサーリンク
