[要約] 要約： RFC 2502は、大規模なマルチキャスト環境における分散シミュレーションのためのインターネットプロトコルスイートの制限について説明しています。目的： このRFCの目的は、インターネットプロトコルスイートが大規模なマルチキャスト環境での分散シミュレーションに適していない制限を明確にすることです。
Network Working Group M. Pullen
Request for Comments: 2502 George Mason University
Category: Informational M. Myjak
The Virtual Workshop
C. Bouwens
SAIC
February 1999
Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment
大規模マルチキャスト環境での分散シミュレーションのためのインターネットプロトコルスイートの制限
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
大規模マルチキャストアプリケーション（LSMA）ワーキンググループは、リアルタイム分散シミュレーションを含む大規模マルチキャストアプリケーションをサポートするインターネットプロトコルのコンセンサスベースの開発を目的としたドキュメントを作成するために設立されました。このメモは、LSMAが必要であると判断したサービスと、LSMAがこれらの要件を満たすためにさらなる開発が必要であると判断したインターネットプロトコルの側面を定義しています。
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].
大規模マルチキャストアプリケーションワーキンググループ（LSMA）は、分散型インタラクティブシミュレーション（DIS）[DIS94]をサポートするインターネットプロトコルのコンセンサスベースの要件を作成するために結成されました。関連アプリケーション。アプリケーションの特徴は、数千から数万のホスト数が状態データを十分な信頼性と適時性で交換して、データを維持できるように、リアルタイムアプリケーションをスケーラブルな方法で共有ワイドエリアネットワークに分散する必要があることです。多数の移動オブジェクトを含む3次元仮想視覚環境。そのようなシステムをサポートするネットワークは、必然的にマルチキャストが可能になるでしょう[IEEE95a、IEEE95b]。
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].
分散インタラクティブシミュレーションは、仮想環境に関する情報を、分散環境内のオブジェクトの動作をシミュレートする分散システム内のホスト間で交換するために使用されるプロトコルファミリの名前です。オブジェクトは物理的な相互作用が可能であり、視覚的およびその他の手段（赤外線など）によって互いに感知できます。 DISは、軍事訓練、リハーサル、その他の目的でシステムを実装するために米国国防総省（DoD）によって開発されました。 DISの詳細については、[SSM96]を参照してください。
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.
ネットワーク要件を推進する分散シミュレーションの特徴は、分散シミュレータ全体で人間との間の出力をリアルタイムで操作することを目的とすることです。これにより、ホスト間のレイテンシが厳しく制限されます。また、実際のネットワークでは、参加しているすべてのシミュレーターにすべてのデータを配信するために、マルチキャストが必要です。大規模な分散シミュレーション構成では、仮想環境で同じセンサー入力を共有することに基づいて、マルチキャストグループでホストをグループ化することが期待されます。これは、オブジェクトが大量にグループ間を高速で移動する可能性がある数千のマルチキャストグループの必要性を意味します。シミュレータの数は事前にわかっており、それらの最大出力レートがパケット/秒およびビット/秒で指定されているため、全体の合計データレート（すべてのマルチキャストグループの合計）が制限されます。ただし、特定のグループで必要なデータレートは予測できず、シミュレーション中に急激に変化する可能性があります。
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秒あたり.2パケットからシミュレータあたり1秒あたり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.
米国国防総省は、最大100,000のシミュレートされたオブジェクトを備えた分散シミュレーションシステムを構築することを目標としています。その多くは、人間の介入を最小限に抑えて実行されるコンピューター生成の力であり、対抗する力として機能するか、参加できない友好的な力をシミュレートします。 DoDは、共有WANを使用してこのようなシミュレーションを実行したいと考えています。 DoDを超えて、多くの人々は、分散シミュレーション機能が娯楽として商業化される可能性を認識しています。このようなエンターテインメントシステムの範囲は予測が困難ですが、DoDの目標である100,000よりも大きくなる可能性があります。
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.
高レベルアーキテクチャ（HLA）は、DISを超えたDoD開発であり、DISおよびその他の形式の分散シミュレーションを統合システムパラダイムに組み込むことを目的としています。分散システムの観点から見ると、HLAはDISよりもかなり高度です。たとえば、分散オブジェクトの属性は、さまざまなシミュレータで制御できます。サポートネットワークの観点から見ると、HLAとDISの主な違いは、HLAがオブジェクト属性の冗長な送信を要求しないことです。代わりに、データを確実に送信する「ランタイムインフラストラクチャ」（RTI）を指定し、ベストエフォートプロトコルを使用した冗長送信を含むさまざまな手段で送信を選択できます。 DISのニーズを満たすことができるすべてのネットワークがDISのような冗長伝送によってHLAをサポートできると言うのは妥当ですが、このアプローチは、HLAの下で冗長伝送と信頼性のある伝送の混合がネットワークリソースの使用を大幅に改善する可能性を無視しますDISを使用して可能です。 DISと同様に、HLAはマルチキャストネットワークの使用を指定していませんが、マルチキャスティングなしでは満たすことができない1秒あたり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つのソリューションは、多数のマルチキャストグループのコンテンツを1つのマルチキャスト送信に集約することです[PuWh95、CSTH95]。 「デュアルモード」または「バイレベル」マルチキャストと呼ばれるこのアプローチは、特定のマルチキャストグループ内のトラフィック量は大幅に変動する可能性があるにもかかわらず、すべての送信の集約が制限されるという事実を利用しています。トラフィックがすべて1つの大きなフローに集約される場合、基盤となるATMネットワークは、要件をサポートするために、許容できるQoSでマルチキャストSVCを作成できます。また、同じネットワークを共有している可能性がある他のLSMAと競合するのではなく、ルーターの専用コレクション間および専用SVC間で結合が行われるという点で、グループ結合のネットワーク制御問題の境界にもなります。しかし、これは、インターネットとATMプロトコルのハイブリッドである新しい非標準の集約要素をネットワークに追加することを犠牲にして行われます。 RSVPを介して集約予約された純粋なIPネットワークを使用してこのような結果を達成するための要件を以下に示します。
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 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.
防御分散型シミュレーションコミュニティは、2〜20の範囲のサイトに分散された数十から数百のシミュレーションオブジェクトの範囲で、さまざまなシミュレーション演習用のマルチキャスト対応ネットワークを多数作成しています。オブジェクトの数が増えるにつれて、大きなグループ変更率で数千の同時マルチキャストグループを潜在的にサポートするマルチキャストネットワークを構築することは難しい問題であることがわかりました。この防御問題は、商用ネットワークで予想される同様の問題の前兆です。したがって、以下のセクションでは、これらのサービスの提供において今日のインターネットプロトコルを使用する際に発見された必要なサービスと欠点について説明します。IETFに通知して、これらの領域のニーズを満たすプロトコルを生成できるようにすることを目的としています。
2. Distributed Simulation (DIS and HLA) network service requirements.
2. 分散シミュレーション（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％未満が到着しない共有ネットワークで、指定された待ち時間内
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. 機密の軍事シミュレーションに必要なパケットごとの暗号化と認証の形式で、安全なネットワークをサポート
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. 共有ネットワークでの大規模分散シミュレーションにはインターネットプロトコルスイート機能が必要ですが、まだ利用できません。これらは、共有ネットワークで確立されたサービス品質を備えたリアルタイムマルチキャストの必要性に基づいています。 （実装に関する質問はこの説明には含まれていません。たとえば、LSMAに必要なマルチキャストグループ変更の規模をサポートするIPマルチキャストの実装が存在するかどうかは明確ではありませんが、実装の問題であり、 IPマルチキャスト。）
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 Protocol（RSVP）は、事前にコミットされたパフォーマンスレベルで情報フローを管理するためのセットアップとフローベースの情報を提供することを目的としています。この機能は通常、HLA RTIなどのリアルタイムシステムで必要とされるものと見なされています。 RSVPのスケーラビリティ、および非常に動的なフロー制御の変更をサポートするその機能について懸念が提起されました。既存のRTI機能に関して、LSMAの要件は、グループ予約の迅速な変更ではなく、グループメンバーシップの迅速な変更です。これは、既存のRTIでは、大規模分散シミュレーションのすべてのグループの総要件が静的であるためです。ただし、LSMAの現在のRSVPドラフト標準は、フローのグループの予約リソースの集約をサポートしていないため、既存のRTIのニーズを満たしていません。さらに、多数のグループに対して個別の動的予約を使用することを目的とした少なくとも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 Open Shortest Path First（MOSPF）などのルーティングプロトコルによって実行される、まったく異なる機能です。大規模な共有ネットワーク機能で効果的なリソース予約を提供するには、サービス品質要件のコンテキスト内でネットワークを経由するパスを決定するルーティングプロトコルが必要になる場合があります。一例は、提案されたサービス品質パスファースト（QOSPF）ルーティングプロトコル[ZSSC97]です。残念ながら、RSMAを使用してLSMAネットワークを展開する前に、リソース依存型ルーティングの要件を定義することは困難です。
3.2 IP multicast that is capable of taking advantage of all common link layer protocols (in particular, ATM)
3.2 すべての一般的なリンク層プロトコル（特に、ATM）を利用できるIPマルチキャスト
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 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.
IPマルチキャストがイーサネット上で動作する場合、IPマルチキャストパケットは一度送信され、イーサネット層マルチキャストアドレッシングを使用してすべてのレシーバーによって受信されるため、パケットの複製が回避されます。ただし、広域非同期転送モード（ATM）では、データリンク層のマルチキャスト機能を利用する機能は、単一の論理IPサブネット（LIS）を超えてまだ利用できません。これは、（1）IPとATMのスイッチングモデルが十分に異なるため、この機能にはかなり複雑なソリューションが必要であり、（2）IPマルチキャストとATMマルチキャストの明確なアプリケーション要件がなかったことが原因と考えられます。複数のLIS間でのパケット複製を提供します。分散シミュレーションは、このような要件を持つアプリケーションです。
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.);
(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]によって提案されました。 PullenとLavianoはこのコンセプトを実装し[PuLa95]、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）までのReliable Transmission Protocol（SRTP）。カテゴリ（4）は、Starburst [MRTW97]の商用マルチキャストFTPオファリングなどの信頼できるマルチキャストプロトコルでサポートできますが、そのようなプロトコルでは適切な輻輳制御が実証されていません。この目的でReal-Time Streaming Protocol、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をサポートするには、ベストエフォートと信頼性の高いマルチキャストのハイブリッド（必ずしもすべてが同じプロトコルである必要はありません）が必要であり、このハイブリッドの低遅延で信頼性の高い部分は、インターネットプロトコルスイート。
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つです。過去数年間インターネットの成長をサポートするために成功裏に使用されてきたネットワーク管理技術は、このニーズを満たすために拡張することができます。この手法は、管理情報ベース（MIB）と呼ばれるプリミティブに基づいており、非常に低いデータレートで定期的にポーリングされます。ポーリングの受信者はエージェントと呼ばれ、監視されているリモートプロセスと同じ場所に配置されます。エージェントは非常に多くのリソースを吸収しないように単純です。要求プロセスはマネージャと呼ばれ、通常は別のワークステーションの別の場所にあります。 Managerは、簡易ネットワーク管理プロトコル（SNMP）を使用して、特定のドメイン内のすべてのエージェントと通信します。 SNMPは、基礎となるシミュレーションネットワークリソースの管理に加えて、分散シミュレーション管理の目的によく適合しているようです。標準の分散シミュレーションMIB形式を作成すると、シミュレーションコミュニティが、SNMPを中心に作成された強力な既製のネットワーク管理ツールのコレクションを利用できるようになります。
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.
大規模な分散エクササイズの開始、停止、一時停止を調整することは複雑で困難な作業です。マルチパーティマルチメディアセッション制御（MMUSIC）ワーキンググループによって最近提案されたセッション開始プロトコル（SIP）は、大規模マルチメディア会議を管理するために同様の目的を果たします。提案されているように、IETFによって標準化されている場合、SIPはエクササイズセッション制御に使用するのに十分な拡張性を提供するように見えます。
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プロトコルでは、実装者は、金融コミュニティなどの厳しいセキュリティ要求のあるコミュニティによるインターネットの使用に必要な整合性、信頼性、および機密性を提供する統合セキュリティアーキテクチャに従う必要があります。 IPv6セキュリティアーキテクチャが軍事的ニーズを満たす可能性がある場合、軍事用暗号化または政府認定の商用暗号化のいずれかと組み合わせると、さらに調査する価値があります。
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.
インターネットでの名前からアドレスへのマッピングは、ドメインネームサービス（DNS）によって実行されます。 DNSには、信頼性の高い伝送（TCP）を備えたユニキャストネットワーキングのニーズに合わせて調整された分散アーキテクチャがあり、レイテンシが1秒以上の場合は問題ないと見なされます。マルチキャストグループ間の俊敏な移動のための分散シミュレーションの要件は、名前解決とグループ結合を組み合わせた場合に、1秒未満のレイテンシで名前からマルチキャストアドレスへのマッピングが必要であることを意味します。この問題は、名前ではなくグループIPアドレスを使用することにより、軍事シミュレーションで回避されました。グリッドスクエアからマルチキャストグループへの既知のマッピングを使用して通信する軍事シミュレーションは満足できるかもしれませんが、分散シミュレーションの商用エンターテインメントへの成長は、このような単純な機能に基づくことはできません。分散型エンターテインメントシミュレーションのプレイヤーは、仮想世界と役割によって象徴的に編成される必要があります。低レイテンシのマルチキャストネーミングサービスが必要になります。
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 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.
軍用LSMAは通常、単一の管理ドメイン内で発生しますが、将来のエンターテイメントLSMAは、ドメイン間マルチキャストトラフィックが大量に発生することが予想されるため、複数のサービスプロバイダーがプレーヤーをサポートできます。このためには、ドメインの境界を越えて多数のマルチキャストフローをサポートできる標準化されたプロトコルが必要になります。ボーダーゲートウェイマルチキャストプロトコル（BGMP）を作成する現在の作業は、このニーズを満たす見込みを示しています。
[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。、他その他、「STOWリアルタイム情報転送およびネットワークアーキテクチャ」、第12回DISワークショップ、相互運用性分散シミュレーションの標準、1995年3月。
[Cohe94] Cohen, D., "Back to Basics," Proceedings of the 11th Workshop on Standards for Distributed Interactive Simulation, Orlando, FL, September 1994.
[Cohe94] Cohen、D。、「Back to Basics」、第11回ワークショップの標準、分散インタラクティブシミュレーションの標準、オーランド、FL、1994年9月。
[DIS94] DIS Steering Committee, "The DIS Vision," Institute for Simulation and Training, University of Central Florida, May 1994.
[DIS94] DIS運営委員会、「DISビジョン」、1994年5月、セントラルフロリダ大学シミュレーションおよびトレーニング研究所
[DMSO96] Defense Modeling and Simulation Office, High Level Architecture Rules Version 1.0, U.S. Department of Defense, August 1996.
[DMSO96]防衛モデリングおよびシミュレーションオフィス、高水準アーキテクチャルールバージョン1.0、米国国防総省、1996年8月。
[IEEE95a] IEEE 1278.1-1995, Standard for Distributed Interactive Simulation - Application Protocols
[IEEE95a] IEEE 1278.1-1995、分散インタラクティブシミュレーションの標準-アプリケーションプロトコル
[IEEE95b] IEEE 1278.2-1995, Standard for Distributed Interactive Simulation - Communication services and Profiles
[IEEE95b] IEEE 1278.2-1995、分散インタラクティブシミュレーションの標準-通信サービスとプロファイル
[MRTW97] Miller, K., et. al. "StarBurst Multicast File Transfer Protocol (MFTP) Specification", Work in Progress.
[MRTW97]ミラー、K。、等。 al。 「StarBurst Multicast File Transfer Protocol（MFTP）Specification」、作業中。
[Mont97] Montgomery, T., Reliable Multicast Links webpage,
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] Pullen、M。およびV. Laviano、「分散インタラクティブシミュレーション用の選択的に信頼できるトランスポートプロトコル」、第13回ワークショップの分散インタラクティブシミュレーション標準に関するワークショップ、オーランド、FL、1995年9月。
[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] Pullen、M.およびE. White、「Dual-Mode Multicast：A New Multicasting Architecture for Distributed Interactive Simulation」、第12回DIS Workshop on Standards for Interoperability of Distributed Simulations、フロリダ州オーランド、1995年3月。
[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] Pullen、M.、Laviano、V。、およびM. Moreau、「選択的に信頼できる伝送を使用したデュアルモードマルチキャストの進化としての軽量RTIの作成」、第2シミュレーション相互運用ワークショップ、フロリダ州オーランド1997年9月。
[SPW94] Symington, S., Pullen, M. and D. Wood, "Modeling and Simulation Requirements for IPng", RFC 1667, August 1994.
[SPW94] Symington、S.、Pullen、M。、およびD. Wood、「IPngのモデリングおよびシミュレーション要件」、RFC 1667、1994年8月。
[SSM96] Seidensticker, S., Smith, W. and M. Myjak, "Scenarios and Appropriate Protocols for Distributed Interactive Simulation", Work in Progress.
[SSM96] Seidensticker、S.、Smith、W。およびM. Myjak、「シナリオと分散型インタラクティブシミュレーションの適切なプロトコル」、進行中。
[ZSSC97] Zhang, Z., et. al., "Quality of Service Path First Routing Protocol", Work in Progress.
[ZSSC97] Zhang、Z。、他その他、「Quality of Service Path First Routing Protocol」、Work in Progress。
Security issues are discussed in section 3.6.
セキュリティの問題については、セクション3.6で説明します。
J. Mark Pullen Computer Science/C3I Center MS 4A5 George Mason University Fairfax, VA 22032
J.マークプレンコンピュータサイエンス/ C3IセンターMS 4A5ジョージメイソン大学フェアファックス、バージニア州22032
EMail: mpullen@gmu.edu
Michael Myjak The Virtual Workshop P.O. Box 98 Titusville, FL 32781
マイケル・ミヤクThe Virtual Workshop P.O. Box 98タイタスビル、FL 32781
EMail: mmyjak@virtualworkshop.com
Christina Bouwens ASSET Group, SAIC Inc. Orlando, FL
Christina Bouwens ASSET Group、SAIC Inc.オーランド、フロリダ州
EMail: christina.bouwens@cpmx.mail.saic.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。