RFC2502 日本語訳

Network Working Group                                           M. Pullen
Request for Comments: 2502                        George Mason University
Category: Informational                                          M. Myjak
                                                     The Virtual Workshop
                                                               C. Bouwens
                                                                     SAIC
                                                            February 1999

コメントを求めるワーキンググループM.ピューレンの要求をネットワークでつないでください: 2502年のジョージメイスン大学Category: 仮想の情報のM.MyjakのワークショップC.Bouwens SAIC1999年2月

   Limitations of Internet Protocol Suite for Distributed Simulation
                   in the Large Multicast Environment

大きいマルチキャスト環境における分配されたシミュレーションのためのインターネットプロトコル群の限界

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   The Large-Scale Multicast Applications (LSMA) working group was
   chartered to produce documents aimed at a consensus based development
   of the Internet protocols to support large scale multicast
   applications including real-time distributed simulation.  This memo
   defines services that LSMA has found to be required, and aspects of
   the Internet protocols that LSMA has found to need further
   development in order to meet these requirements.

Large-スケールMulticast Applications(LSMA)ワーキンググループは、リアルタイムの分配されたシミュレーションを含む大規模マルチキャストアプリケーションをサポートするためにインターネットプロトコルのコンセンサスに基づいている開発が目的とされたドキュメントを製作するためにチャーターされました。 このメモは、これらの必要条件を満たすためにさらなる開発を必要とするようにLSMAが必要であることがわからせているサービス、およびLSMAが見つけたインターネットプロトコルの局面を定義します。

1. The Large Multicast Environment

1. 大きいマルチキャスト環境

   The Large-Scale Multicast Applications working group (LSMA) was
   formed to create a consensus based requirement for Internet Protocols
   to support Distributed Interactive Simulation (DIS) [DIS94], its
   successor the High Level Architecture for simulation (HLA) [DMSO96],
   and related applications. The applications are characterized by the
   need to distribute a real-time applications over a shared wide area
   network in a scalable manner such that numbers of hosts from a few to
   tens of thousands are able to interchange state data with sufficient
   reliability and timeliness to sustain a three dimensional virtual,
   visual environment containing large numbers of moving objects.  The
   network supporting such an system necessarily will be capable of
   multicast [IEEE95a,IEEE95b].

Large-スケールMulticast Applicationsワーキンググループ(LSMA)は、インターネットプロトコルがシミュレーション(HLA)[DMSO96]、および関連出願のためにDistributed Interactive Simulation(DIS)[DIS94]、後継者がHigh Level Architectureであるとサポートするというコンセンサスに基づいている要件を作成するために形成されました。 アプリケーションが共有された広域ネットワークの上のスケーラブルな方法におけるリアルタイムのアプリケーションを配布する必要性によって特徴付けられるので、いくつかから何万までのホストの数は多くの動くオブジェクトを含む三次元仮想の、そして、視覚の環境を支えるために十分な信頼性とタイムリーで州のデータを交換できます。 そのようなシステムをサポートするネットワークは必ずマルチキャスト[IEEE95a、IEEE95b]ができるでしょう。

Pullen                       Informational                      [Page 1]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[1ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   Distributed Interactive Simulation is the name of a family of
   protocols used to exchange information about a virtual environment
   among hosts in a distributed system that are simulating the behavior
   of objects in that environment.  The objects are capable of physical
   interactions and can sense each other by visual and other means
   (infrared, etc.).  DIS was developed by the U.S. Department of
   Defense (DoD) to implement systems for military training, rehearsal,
   and other purposes. More information on DIS can be found in [SSM96].

分配されたInteractive Simulationは分散システムにおけるその環境における、オブジェクトの動きをシミュレートしているホストの中で仮想環境に関して情報交換するのに使用されるプロトコルのファミリーの名前です。 オブジェクトは、物理的な相互作用ができて、視覚の、そして、他の手段(赤外線など)で互いを感じることができます。 DISは、軍事教育、リハーサル、および他の目的のシステムを導入するために米国国防総省(DoD)によって開発されました。 [SSM96]でDISに関する詳しい情報を見つけることができます。

   The feature of distributed simulation that drives network
   requirements is that it is intended to work with output to and input
   from humans across distributed simulators in real time. This places
   tight limits on latency between hosts.  It also means that any
   practical network will require multicasting to implement the required
   distribution of all data to all participating simulators.  Large
   distributed simulation configurations are expected to group hosts on
   multicast groups based on sharing the same sensor inputs in the
   virtual environment.  This can mean a need for thousands of multicast
   groups where objects may move between groups in large numbers at high
   rates.  Because the number of simulators is known in advance and
   their maximum output rate in packets per second and bits per second
   is specified, the overall total data rate (the sum of all multicast
   groups) is bounded. However the required data rate in any particular
   group cannot be predicted, and may change quite rapidly during the
   simulation.

ネットワーク要件を追い立てる分配されたシミュレーションの特徴はリアルタイムで分配されたシミュレータの向こう側に人間からの出力と入力で働いているのが意図しているということです。 これはホストの間にきつい限界を潜在に置きます。 また、それは、どんな実用的なネットワークもすべてのデータの必要な分配をすべて参加しているシミュレータに実装するためにマルチキャスティングを必要とすることを意味します。 仮想環境における同じセンサ入力を共有することに基づいて大きい分散シミュレーション・コンフィギュレーションがマルチキャストグループでホストを分類すると予想されます。 これは物体がグループの間で数多く高い率で移行するかもしれない何千ものマルチキャストグループの必要性を意味できます。 シミュレータの数があらかじめ、知られていて、1秒あたりのパケットとbpsにおけるそれらの最大出力率が指定されるので、総数データ信号速度(すべてのマルチキャストグループの合計)は境界があります。 しかしながら、どんな特定のグループでも必要なデータ信号速度は、予測できないで、シミュレーションの間、全く急速に変化するかもしれません。

   DIS real time flow consists of packets of length around 2000 bits at
   rates from .2 packets per second per simulator to 15 packets per
   second per simulator. This information is intentionally redundant and
   is normally transmitted with a best effort transport protocol (UDP).
   In some cases it also is compressed.  Required accuracy both of
   latency and of physical simulation varies with the intended purpose
   but generally must be at least sufficient to satisfy human
   perception.  For example, in tightly coupled simulations such as high
   performance aircraft maximum acceptable latency is 100 milliseconds
   between any two hosts.  At relatively rare intervals events (e.g.
   collisions) may occur which require reliable transmission of some
   data, on a unicast basis, to any other host in the system.

DISのリアルタイムの流動は1秒あたりの1シミュレータあたりの秒あたり.2のパケットから15のパケットまでのレートにおけるおよそ2000ビットの長さのパケットからシミュレータ単位で成ります。 この情報は、故意に余分であり、通常、ベストエフォート型トランスポート・プロトコル(UDP)で伝えられます。 いくつかの場合、また、それは圧縮されます。 潜在と物理的なシミュレーションの必要な精度は、本来の目的で異なりますが、一般に、人間の知覚を満たすために少なくとも十分でなければなりません。 例えば、高性能などの密結合シミュレーションで、航空機の最大の許容できる潜在はどんな2人のホストの間の100ミリセカンドです。 比較的まれな間隔で、いくつかのデータの信頼できる伝達を必要とするイベント(例えば、衝突)は起こるかもしれません、ユニキャストベースで、システムのいかなる他のホストにも。

   The U.S. DoD has a goal to build distributed simulation systems with
   up to 100,000 simulated objects, many of them computer generated
   forces that run with minimal human intervention, acting as opposing
   force or simulating friendly forces that are not available to
   participate.  DoD would like to carry out such simulations using a
   shared WAN.  Beyond DoD many people see a likelihood that distributed
   simulation capabilities may be commercialized as entertainment.  The
   scope of such an entertainment system is hard to predict but
   conceivably could be larger than the DoD goal of 100,000.

米国DoDには、オブジェクトを最大10万があるシステムがシミュレートした分配されたシミュレーションに造る目標があります、仮想敵として機能するか、または参加するために利用可能でない友軍をシミュレートして。それらの多くがオブジェクトのための最小量の人間の介入と共に経営しているコンピューター生成部隊 DoDは、共有されたWANを使用することでそのようなシミュレーションを行いたがっています。 DoDを超えて、多くの人々が分配されたシミュレーション能力がエンターテインメントとして商業化されるかもしれないという見込みを見ます。 そのようなエンターテインメントシステムの範囲は、予測しにくいのですが、多分10万のDoD目標より大きいかもしれません。

Pullen                       Informational                      [Page 2]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[2ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   The High Level Architecture (HLA) is a DoD development beyond DIS
   that aims at bringing DIS and other forms of distributed simulation
   into a unifying system paradigm. From a distributed systems
   standpoint HLA is considerably more sophisticated than DIS. For
   example attributes of distributed objects may be controlled by
   different simulators.  From the standpoint of the supporting network
   the primary difference between HLA and DIS is that HLA does not call
   for redundant transmission of object attributes; instead it specifies
   a "Run Time Infrastructure" (RTI) that is responsible to transmit
   data reliably, and may choose to do so by various means including
   redundant transmission using best effort protocols. It is reasonable
   to say that any network that can meet the needs of DIS can support
   HLA by DIS-like redundant transmission, however this approach ignores
   the possibility that under HLA some mixture of redundant and reliable
   transmission can make significantly better use of network resources
   than is possible using DIS.  While HLA, like DIS, does not specify
   use of a multicasting network, it has similar requirements for many-
   to-many transmission of object attributes at rates in excess of one
   update per object per second that cannot be met without multicasting.
   Further, HLA calls for transmission of semantically organized data
   (for example, groups of objects with similar capabilities such as
   tanks or aircraft) in this many-to-many context.

High Level Architecture(HLA)はDISと他の形式の分配されたシミュレーションを統一されているシステムパラダイムにもたらすのを目的とするDISを超えたDoD開発です。 分散システム見地から、HLAはDISよりかなり高性能です。 例えば分散オブジェクトの属性は異なったシミュレータによって制御されるかもしれません。 サポートネットワークの見地から、HLAとDISのプライマリ違いはHLAがオブジェクト属性の余分な送信を求めないということです。 代わりに、それは、データを確かに送るのにおいて責任がある「ランタイムインフラストラクチャ」(RTI)を指定して、ベストエフォート型プロトコルを使用することであの手この手で余分なトランスミッションを含んでいて、そうするのを選ぶかもしれません。 しかしながら、DISの需要を満たすことができるどんなネットワークもDISのような余分なトランスミッションでHLAをサポートすることができて、このアプローチが余分で信頼できるトランスミッションのある混合物がHLAの下では、ネットワーク資源のDISを使用することで可能であるよりかなり良い使用をすることができる可能性を無視すると言うのは妥当です。 HLAがDISのようにマルチキャスティングネットワークの使用を指定しませんが、それには多くのための同様の要件がある、-、多く、マルチキャスティングなしでそれに1つのアップデートを超えたレートにおけるオブジェクト属性について1秒あたりのオブジェクトあたり送信して、会うことができません。 さらに、HLAはこの多くへの多く文脈における、意味的に組織化されたデータ(例えば、タンクか航空機などの同様の能力があるオブジェクトのグループ)の伝達を求めます。

   One solution that has been employed to deal with these challenges is
   to aggregate the contents of many multicast groups into a single
   multicast transmission [PuWh95, CSTH95].  Termed "dual-mode" or "bi-
   level" multicast, this approach takes advantage of the fact that
   although the amount of traffic in any particular multicast group can
   vary greatly, the aggregate of all transmissions is bounded. If the
   traffic is all aggregated into one large flow, an underlying ATM
   network can create multicast SVCs with acceptable QoS to support the
   requirement. It also bounds the network control problem of group
   joins, in that the joins take place among dedicated collections of
   routers and across the dedicated SVCs, rather than contending with
   other LSMAs that may be sharing the same network. But it does this at
   the cost of adding to the network a new, nonstandard aggregation
   element that is a hybrid of the Internet and ATM protocols. We
   address below the requirement to achieve such a result using a purely
   IP network with aggregated reservation via RSVP.

これらの挑戦に対処するのに使われた1つのソリューションはただ一つのマルチキャスト送信[PuWh95、CSTH95]への多くのマルチキャストグループのコンテンツに集めることです。 呼ばれた「デュアル・モード」か「2レベル」マルチキャスト、このアプローチはどんな特定のマルチキャストグループでも、トラフィックの量が大いに異なることができますが、すべてのトランスミッションの集合は境界があるという事実を利用します。 トラフィックが1回の大きい流れにすべて集められるなら、基本的なATMネットワークは、要件をサポートするために許容できるQoSとマルチキャストSVCsを作成できます。 それ、グループのネットワーク制御問題がそれに接合する領域、もルータのひたむきな収集の中で行われて、それがもう一方LSMAsであるかもしれないことを競争するよりむしろ専用SVCsの向こう側に同じネットワークを共有しながら、接合します。 しかし、それはインターネットとATMプロトコルのハイブリッドである新しくて、標準的でない集合要素をネットワークに追加する費用でこれをします。 私たちは以下で純粋にaを使用して、IPがRSVPを通して集められることで予約をネットワークでつなぐというそのような結果を獲得するという要件を扱います。

   The defense distributed simulation community has created a number of
   multicast-capable networks for various simulated exercises, ranging
   from tens to hundreds of simulated objects distributed across numbers
   of sites ranging from two to twenty. As the number of objects has
   increased they have found that building multicasting networks
   potentially supporting thousands of simultaneous multicast groups
   with large group change rates is a hard problem. This defense problem
   is the precursor of similar problems that can be expected in

ディフェンスの分配されたシミュレーション共同体は様々なシミュレートされた運動のための多くのマルチキャストできるネットワークを創設しました、10〜シミュレートされた2〜20まで及びながらサイトの数の向こう側に分配された何百個ものオブジェクトまで及んで。 オブジェクトの数が増加するのに従って、それらは、大きい集団変化率で潜在的に何千もの同時のマルチキャストグループをサポートするマルチキャスティングネットワークを造るのが、難問であることがわかりました。 このディフェンス問題はそれを予想できる同様の問題の先駆です。

Pullen                       Informational                      [Page 3]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[3ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   commercial networks.  Therefore the following sections describe the
   services required and the shortcomings that have been found in using
   today's Internet protocols in providing these services, with the
   intention of informing the IETF to enable it to produce protocols
   that meet the needs in these areas.

商業ネットワーク。 したがって、以下のセクションはこれらのサービスを提供する際に今日のインターネットプロトコルを使用する際に必要であるサービスと見つけられた短所について説明します、IETFに知らせるのがこれらの領域で需要を満たすプロトコルを作成するのを可能にするという意志で。

2. Distributed Simulation (DIS and HLA) network service requirements.

2. 分配されたSimulation(DISとHLA)はサービス要件をネットワークでつなぎます。

   a. real-time packet delivery, with low packet loss (less than 2%),
   predictable latency on the order of a few hundred milliseconds, after
   buffering to account for jitter (variation of latency) such that less
   than 2% of packets fail to arrive within the specified latency, in a
   shared network

a. 低いパケット損失(2%未満)、ジター(潜在の変化)のために2%未満のパケットが指定された潜在の中で共用回線網に到着しないようなものをアカウントにバッファリングした後の数100ミリセカンドの注文での予測できる潜在があるリアルタイムのパケット配信

   b. multicasting with thousands of multicast groups that can support
   join latencies of less than one second, at rates of hundreds of joins
   per second

b. 缶のサポートが数百のレートにおける1秒未満の潜在を接合する何千ものマルチキャストグループがあるマルチキャスティングは1秒単位で接合します。

   c. multicasting using a many-to-many paradigm in which 90% or more of
   the group members act as receivers and senders within any given
   multicast group

c. どんな与えられたマルチキャストの中の受信機と送付者が分類するのでグループメンバー条例のどの90%以上に多くへの多くパラダイムを使用するマルチキャスティング

   d. support for resource reservation; because of the impracticality of
   over-provisioning the WAN and the LAN for large distributed
   simulations, it is important to be able to reserve an overall
   capacity that can be dynamically allocated among the multicast groups

d. 資源予約のサポート。 大きい分配されたシミュレーションのためにWANとLANに食糧を供給し過ぎる実行不可能のために、マルチキャストグループにダイナミックに割り当てることができる全能力を予約できるのは重要です。

   e. support for a mixture of best-effort and reliable low-latency
   multicast transport, where best-effort predominates in the mixture,
   and the participants in the reliable multicast may be distributed
   across any portion of the network

e. マルチキャストがベストエフォート型であるところに輸送するベストエフォート型の、そして、信頼できる低遅延の混合物のサポートは混合物の中に勝っています、そして、信頼できるマルチキャストの関係者はネットワークのどんな部分の向こう側にも分配されるかもしれません。

   f. support for secure networking, in the form of per-packet
   encryption and authentication needed for classified military
   simulations

f. 1パケットあたりの暗号化と分類された軍事のシミュレーションに必要である認証の形における安全なネットワークのサポート

3. Internet Protocol Suite facilities needed and not yet available for
   large-scale distributed simulation in shared networks: These derive
   from the need for real-time multicast with established quality of
   service in a shared network.  (Implementation questions are not
   included in this discussion.  For example, it is not clear that
   implementations of IP multicast exist that will support the required
   scale of multicast group changes for LSMA, but that appears to be a
   question of implementation, not a limitation of IP multicast.)

3. 必要でまだ共用回線網における大規模な分配されたシミュレーションに利用可能でないインターネットプロトコルSuite施設: これらが確立したサービスの質でリアルタイムのマルチキャストの必要性に共用回線網で由来しています。 (実装質問はこの議論に含まれていません。 例えば、LSMAのためにマルチキャスト集団変化の必要なスケールをサポートしますが、IPマルチキャストの制限ではなく、実装の問題であるように見えるIPマルチキャストの実装が存在するのは、明確ではありません。)

Pullen                       Informational                      [Page 4]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[4ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

3.1 Large-scale resource reservation in shared networks

3.1 共用回線網における大規模な資源予約

   The Resource reSerVation Protocol (RSVP) is aimed at providing setup
   and flow-based information for managing information flows at pre-
   committed performance levels.  This capability is generally seen as
   needed in real-time systems such as the HLA RTI. Concerns have been
   raised about the scalability of RSVP, and also about its ability to
   support highly dynamic flow control changes.  In terms of existing
   RTI capabilities, the requirement in LSMA is for rapid change of
   group membership, not for rapid change of group reservations.  This
   is because in existing RTIs the aggregate requirement for all groups
   in a large scale distributed simulation is static. However the
   current RSVP draft standard for LSMA does not support aggregation of
   reservation resources for groups of flows and therefore does not meet
   the needs of existing RTIs.  Moreover, there is at least one RTI
   development underway that intends to use individual, dynamic
   reservations for large numbers of groups, and therefore will require
   a dynamic resource reservation capability that scales to thousands of
   multicast groups.

Resource reSerVationプロトコル(RSVP)はセットアップを提供するのを目的とされます、そして、情報を管理するための流れベースの情報はあらかじめ遂行された性能レベルで流れます。 一般に、HLA RTIなどのリアルタイムのシステムのこの能力は必要に応じて見られます。 関心はRSVPのスケーラビリティの周りと、そして、非常にダイナミックなフロー制御変化をサポートするその性能の周りに関しても高められました。 既存のRTI能力に関して、LSMAの要件はグループの予約の急激な変化ではなく、グループ会員資格の急激な変化のためのものです。 これは大規模分配されたシミュレーションにおけるすべてのグループのための集合要件が既存のRTIsで静的であるからです。 しかしながら、LSMAの現在のRSVP草稿規格は、流れのグループのための予約リソースの集合をサポートしないで、またしたがって、既存のRTIsの需要を満たしません。 そのうえ、多くのグループの個々の、そして、ダイナミックな予約を使用するつもりであり、したがって何千ものマルチキャストグループに比例するダイナミックな資源予約能力を必要とする進行中の少なくとも1つのRTI開発があります。

   Further, RSVP provides support only for communicating specifications
   of the required information flows between simulators and the network,
   and within the network.  Distributing routing information among the
   routers within the network is a different function altogether,
   performed by routing protocols such as Multicast Open Shortest Path
   First (MOSPF). In order to provide effective resource reservation in
   a large shared network function, it may be necessary to have a
   routing protocol that determines paths through the network within the
   context of a quality of service requirement.  An example is the
   proposed Quality Of Service Path First (QOSPF) routing protocol
   [ZSSC97]. Unfortunately the requirement for resource-sensitive
   routing will be difficult to define before LSMA networks are deployed
   with RSVP.

さらに、RSVPは、シミュレータとネットワークの間と、そして、ネットワークの中で必須情報流れの仕様を伝えながら、サポートに備えるだけです。 ネットワークの中でルーティング情報をルータに分配するのは、全体で異なった機能です、MulticastオープンShortest Path First(MOSPF)などのルーティング・プロトコルによって実行されて。 大きい共用回線網機能に有効な資源予約を提供するために、サービスの質要件の文脈の中のネットワークを通して経路を決定するルーティング・プロトコルを持つのが必要であるかもしれません。 例は提案されたQuality Of Service Path First(QOSPF)ルーティング・プロトコル[ZSSC97]です。 残念ながら、LSMAネットワークがRSVPと共に配布される前に定義するのはリソース敏感なルーティングのための要件が難しくなるでしょう。

3.2 IP multicast that is capable of taking advantage of all common
    link layer protocols (in particular, ATM)

3.2 すべての普通リンク層のプロトコルを利用できるIPマルチキャスト(特にATM)

    Multicast takes advantage of the efficiency obtained when the
    network can recognize and replicate information packets that are
    destined to a group of locations. Under these circumstances, the
    network can take on the job of providing duplicate copies to all
    destinations, thereby greatly reducing the amount of information
    flowing into and through the network.

マルチキャストはネットワークが位置のグループに運命づけられている情報パケットを認識して、模写できるなら得られた効率を利用します。 こういう事情ですから、ネットワークはすべての目的地に写本を提供する仕事を引き受けることができます、その結果、ネットワークの中と、そして、ネットワークを通して流れる情報量を大いに減少させます。

    When IP multicast operates over Ethernet, IP multicast packets are
    transmitted once and received by all receivers using Ethernet-layer
    multicast addressing, avoiding replication of packets.  However,
    with wide-area Asynchronous Transfer Mode (ATM), the ability to take

IPマルチキャストがイーサネットの上で作動すると、イーサネット層のマルチキャストアドレシングを使用することでIPマルチキャストパケットを一度送信して、すべての受信機で受け取ります、パケットの模写を避けて。 しかしながら、取る広い領域Asynchronous Transfer Mode(ATM)に伴う能力

Pullen                       Informational                      [Page 5]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[5ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

    advantage of data link layer multicast capability is not yet
    available beyond a single Logical IP Subnet (LIS).  This appears to
    be due to the fact that (1) the switching models of IP and ATM are
    sufficiently different that this capability will require a rather
    complex solution, and (2) there has been no clear application
    requirement for IP multicast over ATM multicast that provides for
    packet replication across multiple LIS.  Distributed simulation is
    an application with such a requirement.

データ・リンク層マルチキャスト能力の利点はまだ独身のLogical IP Subnet(LIS)を超えて利用可能ではありません。 これは(1) IPとATMの切り換えモデルが十分異なっているというこの能力が必要とする事実のために、かなり複雑なソリューション、およびそこの(2)が複数のLISの向こう側にパケット模写に備えるATMマルチキャストの上のIPマルチキャストのための明確なアプリケーション要件でないということであるように見えます。 分配されたシミュレーションはそのような要件があるアプリケーションです。

3.3 Hybrid transmission of best-effort and reliable multicast

3.3 ベストエフォート型の、そして、信頼できるマルチキャストのハイブリッド送信

    In general the Internet protocol suite uses the Transmission Control
    Protocol (TCP) for reliable end-to-end transport, and the User
    Datagram Protocol (UDP) for best-effort end-to-end transport,
    including all multicast transport services.  The design of TCP is
    only capable of unicast transmission.

一般に、インターネット・プロトコル群は終わりから終わりへの信頼できる輸送のための通信制御プロトコル(TCP)、および終わりから終わりへのベストエフォート型輸送のためのユーザー・データグラム・プロトコル(UDP)を使用します、すべてのマルチキャスト輸送サービスを含んでいて。 TCPのデザインはユニキャスト送信ができるだけです。

    Recently the IETF has seen proposals for several reliable multicast
    transport protocols (see [Mont97] for a summary). A general issue
    with reliable transport for multicast is the congestion problem
    associated with delivery acknowledgments, which has made real-time
    reliable multicast transport infeasible to date.  Of the roughly 15
    attempts to develop a reliable multicast transport, all have shown
    to have some problem relating to positive receipt acknowledgments
    (ACK) or negative acknowledgments (NAK). In any event, its seems
    clear that there is not likely to be a single solution for reliable
    multicast, but rather a number of solutions tailored to different
    application domains. Approaches involving distributed logging seem
    to hold particular promise for the distributed simulation
    application.

最近、IETFはいくつかの信頼できるマルチキャストトランスポート・プロトコルのための提案を見ました(概要に関して[Mont97]を見てください)。 マルチキャストのための信頼できる輸送の一般答弁は配送承認に関連している混雑問題です。(その問題はこれまでリアルタイムの信頼できるマルチキャスト輸送を実行不可能にしました)。 信頼できるマルチキャスト輸送を開発するおよそ15の試みでは、すべてが、積極的な領収書承認(ACK)か否定応答(NAK)に関連することにおける何らかの問題を持つために目立ちました。 とにかく、それ、信頼できるマルチキャストにおいて、ただ一つのソリューションがありそうではありませんでしたが、むしろ多くのソリューションが異なったアプリケーションドメインに適合したのが明確に見えます。 分配された伐採にかかわるアプローチは分配されたシミュレーション適用のための特定の見込みを有するように思えます。

    In the DIS/HLA environment, five different transmission needs can be
    identified:

DIS/HLA環境で、異なったトランスミッションが必要とする5を特定できます:

   (1) best-effort low-latency multicast of object attributes that often
       change continuously, for example position of mobile objects;
   (2) low-latency reliable multicast of object attributes that do not
       change continuously but may change at arbitrary times during the
       simulation, for example object appearance (An important
       characteristic of this category is that only the latest value of
       any attribute is needed by the receiver.);
   (3) low-latency, reliable unicast of occasional data among arbitrary
       members of the multicast group (This form of transmission was
       specified for DIS "collisions"; it is not in the current HLA
       specification but might profitably be included there. The
       requirement is for occasional transaction-like exchange of data
       between two arbitrary hosts in the multicast group, with a low
       latency that makes TCP connection impractical.);

(1) しばしば絶え間なく変化するオブジェクト属性のベストエフォート型低遅延マルチキャスト、例えば、モバイルオブジェクトの位置。 (2) 絶え間なく変化しませんが、シミュレーションの間の任意の回、例えば、オブジェクト外観で変化するかもしれない(このカテゴリの重要な特性はどんな属性の最新の値だけも受信機によって必要とされるということです。)オブジェクト属性の低遅延の信頼できるマルチキャスト。 (3) マルチキャストグループの任意のメンバーの中の時々のデータの低い潜在の、そして、信頼できるユニキャスト(この形式の送信はDIS「衝突」に指定されました。 それは、現在のHLA仕様にありませんが、そこに有益に含まれるかもしれません。 マルチキャストグループの2人の任意のホストの間には、要件はデータの時々のトランザクションのような交換のためにあります、TCP接続を非実用的にする低遅延で。);

Pullen                       Informational                      [Page 6]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[6ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   (4) reliable but not necessarily real-time multicast distribution of
       supporting bulk data such as terrain databases and object
       enumerations; and
   (5) reliable unicast of control information between individual RTI
       components (this requirement is met by TCP).

(4) 地勢データベースやオブジェクト列挙などの大量のデータをサポートする信頼できますが、必ずリアルタイムであるというわけではないマルチキャスト分配。 (5) そして、個々のRTIの部品(この必要条件はTCPによって満たされる)の間の制御情報の信頼できるユニキャスト。

   All of these transmissions take place within the same large-scale
   multicasting environment. The value of integrating categories (1) and
   (2) into a single selectively reliable protocol was proposed by Cohen
   [Cohe94].  Pullen and Laviano implemented this concept [PuLa95] and
   demonstrated it within the HLA framework [PLM97] as the Selectively

これらのトランスミッションのすべてが同じ大規模なマルチキャスティング環境の中で行われます。 ただ一つの選択的に信頼できるプロトコルとカテゴリ(1)と(2)を統合する値はコーエン[Cohe94]によって提案されました。 ピューレンとLavianoはこの概念が[PuLa95]であると実装して、SelectivelyとしてHLAフレームワーク[PLM97]の中にそれを示しました。

   Reliable Transmission Protocol (SRTP) for categories (1) through (3).
   Category (4) could be supported by a reliable multicast protocol such
   as the commercial multicast FTP offering from Starburst [MRTW97],
   however adequate congestion control has not been demonstrated in any
   such protocol. There has been some discussion of using the Real-Time
   Streaming Protocol, RTSP, for this purpose, however as the databases
   must be transmitted reliably and RTSP uses a best-effort model, it
   does not appear to be applicable.

カテゴリ(1)から(3)のための信頼できるTransmissionプロトコル(SRTP)。 カテゴリ(4)はStarburstから[MRTW97]を提供する商業マルチキャストFTPなどの信頼できるマルチキャストプロトコルによってサポートされるかもしれなくて、しかしながら、適切な輻輳制御はどんなそのようなプロトコルでも実施説明されていません。 レアル-時間Streamingプロトコルを使用する何らかの議論がありました、RTSP、このために、データベースを確かに伝えなければならなくて、RTSPがベストエフォート型モデルを使用するとき適切であるようにどのように見えないでも。

   In summary, it is clear that a hybrid of best-effort and reliable
   multicast (not necessarily all in the same protocol) is needed to
   support DIS and HLA, and that the low-latency, reliable part of this
   hybrid is not available in the Internet protocol suite.

概要では、ベストエフォート型の、そして、信頼できるマルチキャスト(必ず同じプロトコルのすべてであるというわけではない)のハイブリッドがDIS、HLA、およびそれが低遅延であるとサポートするのに必要であるのが、明確である、このハイブリッドの信頼できる部分はインターネット・プロトコル群で有効ではありません。

3.4 Network management for distributed simulation systems

3.4 分配されたシミュレーション・システムのためのネットワークマネージメント

   Coordinated, integrated network management is one of the more
   difficult aspects of a large distributed simulation exercise.  The
   network management techniques that have been used successfully to
   support the growth of the Internet for the past several years could
   be expanded to fill this need.  The technique is based on a primitive
   called a Management Information Base (MIB) being polled periodically
   at very low data rates.  The receiver of the poll is called an Agent
   and is collocated with the remote process being monitored. The agent
   is simple so as to not absorb very many resources. The requesting
   process is called a Manager, and is typically located elsewhere on a
   separate workstation.  The Manager communicates to all of the agents
   in a given domain using the Simple Network Management Protocol
   (SNMP).  It appears that SNMP is well adapted to the purpose of
   distributed simulation management, in addition to managing the
   underlying simulation network resources.  Creating a standard
   distributed simulation MIB format would make it possible for the
   simulation community to make use of the collection of powerful, off-
   the-shelf network management tools that have been created around
   SNMP.

連携していて、統合しているネットワークマネージメントは大きい分配されたシミュレーション運動の、より難しい局面の1つです。 この必要性をいっぱいにするために過去数年間インターネットの成長をサポートするのに首尾よく使用されたネットワークマネージメントのテクニックは広げることができました。 テクニックは、非常に低いデータ信号速度で定期的に投票されながら、Management Information基地(MIB)と呼ばれる基関数に基づいています。 投票の受信機によるエージェントと呼ばれて、連語をなされて、リモートがモニターされていた状態で存在を処理するということです。 エージェントは、非常に多くのリソースを吸収しないように純真です。 要求プロセスは、マネージャと呼ばれて、別々のワークステーションの上のほかの場所に通常位置しています。 マネージャは、与えられたドメインでSimple Network Managementプロトコル(SNMP)を使用することでエージェントのすべてに交信します。 SNMPが分配されたシミュレーション管理の目的によく適合させられるように見えます、基本的なシミュレーションネットワーク資源を管理することに加えて。 標準の分散シミュレーションMIB形式を作成するのにシミュレーション共同体が強力の収集を利用するのが可能になるだろう、オフである、SNMPの周りで作成された棚のネットワークマネージメントツール。

Pullen                       Informational                      [Page 7]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[7ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

3.5 A session protocol to start, pause, and stop a distributed
    simulation exercise

3.5 始まって、止まって、分配されたシミュレーション運動を止めるセッションプロトコル

   Coordinating start, stop, and pause of large distributed exercises is
   a complex and difficult task.  The Session Initiation Protocol (SIP)
   recently proposed by the Multiparty Multimedia Session Control
   (MMUSIC) working group serves a similar purpose for managing large
   scale multimedia conferences. As proposed, SIP appears to offer
   sufficient extensibility to be used for exercise session control, if
   standardized by the IETF.

大きい分配された運動の始め、停止、およびくぎりを調整するのは、複雑で難しいタスクです。 最近Multiparty Multimedia Session Control(MMUSIC)ワーキンググループによって提案されたSession Initiationプロトコル(SIP)は大規模マルチメディア会議を経営するための同様の目的に役立ちます。 提案されるように、IETFによって標準化されるなら、SIPは、運動セッション制御に使用できるくらいの伸展性を提供するように見えます。

3.6 An integrated security architecture

3.6 統合セキュリティー体系

   It appears that this requirement will be met by IPv6 deployment. A
   shortcoming of the current Internet Protocol (IPv4) implementation is
   the lack of integrated security. The new IPv6 protocol requires
   implementers to follow an integrated security architecture that
   provides the required integrity, authenticity, and confidentiality
   for use of the Internet by communities with stringent security
   demands, such as the financial community.  The possibility that the
   IPv6 security architecture may meet military needs, when combined
   either with military cryptography or government-certified commercial
   cryptography, merits further study.

この必要条件がIPv6展開で満たされるように見えます。 現在のインターネットプロトコル(IPv4)実装の短所は統合セキュリティの不足です。 新しいIPv6プロトコルは、implementersが共同体による厳しい治安上の要求によるインターネットの使用に必要な保全、信憑性、および秘密性を提供する統合セキュリティー体系に従うのを必要とします、金融界などのように。 軍事の暗号か政府によって公認された商業暗号に結合されるとIPv6セキュリティー体系が軍事の需要を満たすかもしれない可能性はさらなる研究に値します。

3.7 Low-latency multicast naming service

3.7 低遅延マルチキャスト名前付けサービス

   Name-to-address mapping in the Internet is performed by the Domain
   Name Service (DNS).  DNS has a distributed architecture tuned to the
   needs of unicast networking with reliable transmission (TCP) that is
   not considered problematic if its latency is on the order of a second
   or more. The requirement of distributed simulation for agile movement
   among multicast groups implies a need for name-to-multicast-address
   mapping with latency of under one second for the name resolution and
   group join combined.  This problem has been circumvented in military
   simulations by using group IP addresses rather than names. While
   military simulations may be satisfied to communicate using a known
   mapping from grid squares to multicast groups, growth of distributed
   simulation into commercial entertainment cannot be based on such a
   simple capability. The players in distributed entertainment
   simulations will want to be organized symbolically by virtual world
   and role. A low-latency multicast naming service will be required.

インターネットの名前からアドレス・マッピングはDomain Name Service(DNS)によって実行されます。 DNSは1秒以上の注文に潜在があるなら問題が多いのは考えられない信頼できるトランスミッション(TCP)でユニキャストネットワークの必要性を分配されたアーキテクチャに調整させます。 マルチキャストグループでのアジャイル運動のための分配されたシミュレーションの要件は、名前解決とグループが加わるので1秒未満の潜在がある名前からマルチキャストアドレス・マッピングの必要性が結合したのを含意します。 この問題は名前よりむしろグループIPアドレスを使用することによって、軍事のシミュレーションで回避されました。 軍事のシミュレーションが格子で区切られた正方形からマルチキャストグループまで知られているマッピングを使用することで交信するので満たされているかもしれない間、商業エンターテインメントへの分配されたシミュレーションの成長はそのような簡単な能力に基づくことができません。 分配されたエンターテインメントシミュレーションにおけるプレーヤーは仮想世界と役割によって象徴的に組織化されたくなるでしょう。 低遅延マルチキャスト名前付けサービスが必要でしょう。

3.8 Inter-Domain Multicast Routing for LSMA

3.8 LSMAのための相互ドメインマルチキャストルート設定

   While military LSMAs typically take place within a single
   administrative domain, future entertainment LSMAs can be expected to
   involve heavy inter-domain multicast traffic so that players can be
   supported by multiple service providers.  Standardized protocols able

軍用のLSMAsがただ一つの管理ドメインの中で通常行われている間、複数のサービスプロバイダーがプレーヤーを支えることができるように将来のエンターテインメントLSMAsが激しい相互ドメインマルチキャストトラフィックにかかわると予想できます。 できる標準化されたプロトコル

Pullen                       Informational                      [Page 8]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[8ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   to support large numbers of multicast flows across domain boundaries
   will be needed for this purpose.  Current work to create a Border
   Gateway Multicast Protocol (BGMP) shows promise of meeting this need.

ドメイン境界の向こう側に多くのマルチキャスト流れをサポートするのがこのために必要でしょう。 BorderゲートウェイMulticastプロトコル(BGMP)を作成する執筆中の作品はこの需要を満たす見込みを示しています。

4.  References

4. 参照

   [CSTH95]  Calvin, J., et. al., "STOW Realtime Information Transfer
             and Networking Architecture," 12th DIS Workshop on
             Standards for the Interoperability Distributed Simulations,
             March 1995.

[CSTH95]カルヴァン、J.et(アル)は「リアルタイムで情報転送とネットワークアーキテクチャを積み込みます」、Interoperability Distributed SimulationsのためのStandardsの上の第12DIS Workshop、1995年3月。

   [Cohe94]  Cohen, D., "Back to Basics," Proceedings of the 11th
             Workshop on Standards for Distributed Interactive
             Simulation, Orlando, FL, September 1994.

D. [Cohe94]コーエン、「基礎」への第11ワークショップの分配された対話的なシミュレーション(オーランド(フロリダ)1994年9月)の規格における議事。

   [DIS94]   DIS Steering Committee, "The DIS Vision," Institute for
             Simulation and Training, University of Central Florida, May
             1994.

[DIS94]は1994年5月に運営委員会、「不-ビジョン」とシミュレーションの研究所とトレーニング、セントラルフロリダ大学をけなします。

   [DMSO96]  Defense Modeling and Simulation Office, High Level
             Architecture Rules Version 1.0, U.S. Department of Defense,
             August 1996.

モデルとシミュレーションオフィス、高い平らなアーキテクチャが1996年8月にバージョン1.0、米国国防総省を統治するという[DMSO96]ディフェンス。

   [IEEE95a] IEEE 1278.1-1995, Standard for Distributed Interactive
             Simulation - Application Protocols

[IEEE95a]IEEE1278.1-1995、分配された対話的なシミュレーションの規格--アプリケーション・プロトコル

   [IEEE95b] IEEE 1278.2-1995, Standard for Distributed Interactive
             Simulation - Communication services and Profiles

[IEEE95b]IEEE1278.2-1995、Distributed Interactive SimulationのためのStandard--通信サービスとProfiles

   [MRTW97]  Miller, K., et. al. "StarBurst Multicast File Transfer
             Protocol (MFTP) Specification", Work in Progress.

[MRTW97] etミラー、K.、アル。 「スターバーストマルチキャストファイル転送プロトコル(MFTP)仕様」、処理中の作業。

   [Mont97]  Montgomery, T., Reliable Multicast Links webpage,
             http://research.ivv.nasa.gov/RMP/links.html

[Mont97] モンゴメリ、T.、Reliable Multicastリンクスウェブページ、 http://research.ivv.nasa.gov/RMP/links.html

   [PuLa95]  Pullen, M. and V. Laviano, "A Selectively Reliable
             Transport Protocol for Distributed Interactive Simulation",
             Proceedings of the 13th Workshop on Standards for
             Distributed Interactive Simulation, Orlando, FL, September
             1995.

[PuLa95] ピューレン、M.、および「分配された対話的なシミュレーションのための選択的に信頼できるトランスポート・プロトコル」、分配された対話的なシミュレーション(オーランド(フロリダ)1995年9月)のための規格における第13ワークショップの議事対Laviano

   [PuWh95]  Pullen, M. and E. White, "Dual-Mode Multicast: A New
             Multicasting Architecture for Distributed Interactive
             Simulation," 12th DIS Workshop on Standards for the
             Interoperability of Distributed Simulations, Orlando, FL,
             March 1995.

[PuWh95] ピューレン、M.、およびE.ホワイト、「デュアル・モードマルチキャスト:」 「分配された対話的なシミュレーションのための新しいマルチキャスティング構造」、分配されたシミュレーション(1995年のオーランド(フロリダ)の行進)の相互運用性のための規格に関する第12不-ワークショップ。

Pullen                       Informational                      [Page 9]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[9ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

   [PLM97]   Pullen, M., Laviano, V. and M. Moreau, "Creating A Light-
             Weight RTI As An Evolution Of Dual-Mode Multicast Using
             Selectively Reliable Transmission," Proceedings of the
             Second Simulation Interoperability Workshop, Orlando, FL,
             September 1997.

[PLM97] ピューレン、M.、Laviano、V.、およびM.モロー、「光を引き起こして、選択的に信頼できるトランスミッションを使用して、デュアル・モードマルチキャストの発展としてRTIに重みを加えてください」、第2シミュレーション相互運用性ワークショップの議事、オーランド(フロリダ)1997年9月。

   [SPW94]   Symington, S., Pullen, M. and D. Wood, "Modeling and
             Simulation Requirements for IPng", RFC 1667, August 1994.

[SPW94] サイミントンとS.とピューレンとM.とD.木、「IPngのためのモデリングシミュレーション要件」、RFC1667、1994年8月。

   [SSM96]   Seidensticker, S., Smith, W. and M. Myjak, "Scenarios and
             Appropriate Protocols for Distributed Interactive
             Simulation", Work in Progress.

[SSM96] 「分配された対話的なシミュレーションのためのシナリオと適切なプロトコル」というサイデンステッカー、S.、スミス、W.、およびM.Myjakは進行中で働いています。

   [ZSSC97]  Zhang, Z., et. al., "Quality of Service Path First Routing
             Protocol", Work in Progress.

[ZSSC97] etアルチャン、Z.、Progressの「サービス経路1番目の品質はプロトコルを発送すること」でのWork。

4.  Security Considerations

4. セキュリティ問題

   Security issues are discussed in section 3.6.

セクション3.6で安全保障問題について議論します。

5.  Authors' Addresses

5. 作者のアドレス

   J. Mark Pullen
   Computer Science/C3I Center
   MS 4A5
   George Mason University
   Fairfax, VA 22032

MS4A5ジョージ・メイスン・大学のフェアファクス、J.マークピューレンコンピュータサイエンス/C3Iセンターヴァージニア 22032

   EMail: mpullen@gmu.edu

メール: mpullen@gmu.edu

   Michael Myjak
   The Virtual Workshop
   P.O. Box 98
   Titusville, FL 32781

タイタスビル、マイケルMyjak仮想のワークショップP.O. Box98フロリダ 32781

   EMail: mmyjak@virtualworkshop.com

メール: mmyjak@virtualworkshop.com

   Christina Bouwens
   ASSET Group, SAIC Inc.
   Orlando, FL

クリスティーナBouwens資産グループ、SAIC株式会社オーランド、フロリダ

   EMail: christina.bouwens@cpmx.mail.saic.com

メール: christina.bouwens@cpmx.mail.saic.com

Pullen                       Informational                     [Page 10]

RFC 2502         Limitations of Internet Protocol Suite    February 1999

インターネットのピューレン[10ページ]情報のRFC2502Limitationsはスイート1999年2月に議定書を作ります。

6.  Full Copyright Statement

6. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Pullen                       Informational                     [Page 11]

ピューレンInformationalです。[11ページ]