HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 04:49:53 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 07 Jan 1997 12:20:00 GMT ETag: "2e9d4f-48b9-32d23f70" Accept-Ranges: bytes Content-Length: 18617 Connection: close Content-Type: text/plain Internet Engineering Task Force Large-Scale Management of Multicast Groups WORKING INTERNET-DRAFT Steve Seidensticker, ed., draft-myjak-lsma-scenarios-00.txt seiden@netcom.com 13 June 1996 W. Garth Smith, wgsmith@tiac.net Michael Myjak myjak@ist.ucf.edu Expires in 6 months Scenarios and Appropriate Protocols for Distributed Interactive Simulation draft-ietf-lsma-scenarios-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. The current working draft is located at the following URL: http://www.tasc.com/simweb/ietf/draft-DISscenarios-00.txt Current schedule: June 1996. Meet in Montreal, approve charter, refine goal documents and finalize the appoint of editors for documents. Sept. 1996. Produce initial draft. Dec. 1996. Review document drafts and accept changes and comments on the documents. March 1997. Publish documents as Informational RFCs Close group. Mailing lists for comments: ietf-dis@bacon.gmu.edu ietf-dis-request@bacon.gmu.edu Abstract We describe Distributed Interactive Simulation (DIS) scenarios from the vantage point of hardware and software vendors who would need to address the network implications and requirements to enable large scale networked multiplayer virtual worlds. This document is meant to migrate the heuristic knowledge of the traditional Department of Defense (DoD) modeling and simulation community into tangible design metrics for the commercial networking community [2]. 0. Introduction Distributed Interactive simulation (DIS) [1] is being extensively used by the DoD as a means providing multi-player virtual worlds for large scale military simulations. A large body of folk knowledge has been accumulated as to the types of scenarios that are possible within the DIS community given the state of network hardware and software. The authors attempt to describe this hueristic knowledge of network requirements in the form of anecdotal scenarios such that the general community be able to characterize simulation requirements from their perspective. This paper provides a series of example scenarios with the details of the required network infrastructure for entity passing among simulation hosts. This initial version of the document is meant to pass through successive iterations. These scenarios may initially be described in a general manner but ultimately may be delivered in a more quantified manner based ob feedback from the June 1996 IETF, in Montreal. DIS simulations are collections of individual simulations linked at a peer level. That is, there is no client/server or centralized kernel. Each simulation application maintains it's own copy of a common virtual environment. Representations of this environment (e.g. terrain databases) are distributed by various means to all simulation applications prior to any real time operation. Issues associated with the distribution of the description of the static environment are not within the scope of this discussion. During real time operation each simulation application models the behavior of the simulated entity(s) for which it is responsible. Whenever specific events occur in the virtual environment or when the state of the simulated entities have changed significantly, the simulation application transmits this new information to the other simulation applications on the network. This information is encapsulated in standard packets, the content and format of which are defined in IEEE standard 1278.1 [1]. These packets are transmitted via the UDP/IP datagram service. Anomalies and lack of precise causality due to dropped packets are tolerated in order to get the latency needed to support real time operations. A next-generation approach to simulation standards is in development which does not explicitly define packets. However, for the purpose of exploring the communication issues identified in this paper, the requirements are similar. Effective DIS simulation depends on low latency between the time a new state/event occurs for a simulated entity to the time that that state/event is perceived by another entity that must react to it (e.g. two high performance aircraft maneuvering to get in position to launch weapons at each other). In event driven simulations increased latency merely slows the simulation down but causality is maintained. In real time simulations excessive latency destroys interactions and the simulation collapses. The DIS recommended practice for communications architecture (IEEE 1278.2) indicates that the underlying communications structure should provide 100 ms or less latency for packet exchange for closely coupled interactions between simulated entities (e.g. high performance aircraft in a dog fight). This requirement is based on human reaction times that have been the basis of human-in-the-loop (HITL) flight simulator designs for many years. This requirement eases to 300 ms for loosely coupled interactions (simulated voice radio). To some extent DIS compensates for excessive latency by extrapolating continuously changing values (e.g. deduced reckoning of entity movement based on initial position plus velocity and acceleration). However, discrete events (e.g. voice exchanges between humans on a simulated radio net) cannot be predicted and therefore no latency compensation is possible. Types of Data Exchanged The IEEE 1278.1 standard identifies 27 different kinds of packets and provides an extension mechanism to handle new data types. Only a few of these tax network services. They are: Entity State -- Information includes appearance, location, velocity, orientation, accelerations, and position/movement of articulated parts of simulated entities. Location and movement are dead reckoned and this packet is only sent to correct dead reckoned parameters. It also is sent periodically, even if the dead reckoned parameters have not changed, as a heartbeat. Radically maneuvering entities transmit up to 15 packets/second. An average rate is two/sec for land vehicles and five/sec for aircraft. Emissions -- Information includes point of origin, power, frequency, direction, scan pattern, and other parameters of electronic or acoustic emissions. This information is used to stimulate simulated sensors capable of detecting and responding to such information. In electronic warfare (EW) environments these parameters change frequently. In an active EW environment emission packets are sent as frequently as entity state packets. Signal -- This packet carries bit streams representing voice samples, computer-to-computer communications, or any other digital bit stream. It is heavily used in simulations that include voice radio or computer based tactical command and control systems. Environment -- Atmospheric data is broken up into a series of packets to describe weather conditions in the simulated environment. The update rate is relatively low, but the number of packets needed to represent complex weather patterns induces a significant network load. Fire & Detonation -- Packet pairs carry the information needed to describe the firing of a ballistic (unguided) weapon and the detonation of the projectile. The amount of information per packet is modest and the total packets are limited to the amount of ammunition the participants can carry, but weapon firing tends to come in bursts and those bursts can impact network performance. Multicasting In early DIS simulations all applications simply broadcast DIS packets to all other applications in the exercise using the IP broadcast address in UDP datagrams. More recent DIS simulations use static multicast addresses to segregate different kinds of packets (e.g. entity state, emissions, signal). This reduces the processing required to throw away packets by those applications that cannot process them. While static multicasting is a significant improvement over broadcasting, it is not adequate for the large scale simulations that the DIS community needs to build (100,000 simulated entities modeled by simulation applications at 50 sites). For that a mechanism must be found that can efficiently route packets only when and where they are needed. Dynamic multicasting is the key. But to use dynamic multicasting it must be supported by the communications community. Much has been said and written about dynamic multicasting. There is no single view of it. Dynamic multicasting can have many characteristics. Different applications will emphasize different characteristics. Those most important to the DIS community are: * Many groups * Many members in a group * Receiver initiated joins and leaves * Rapid joins and leaves * Single member belonging to many groups 1. This scenario is a description of a relatively current small scale DIS simulation. A dedicated 10 megabit/second Ethernet 10Base-T Local Area Network (LAN) has been established for a 200 entity exercise. The simulation platforms are Silicon Graphics (SGI) Indigo 2 Extremes running IRIX 5.3, SGI Maximum Impacts, and SUN Solaris 5.4 SPARC Ultra UNIX workstations. Three stand-alone hosts running an embedded real-time operating system are functioning as high speed aircraft simulators. The aircraft simulators provide high resolution out-the window views of the virtual world. All simulations are using the IEEE 1278-1993 DIS 2.0.4 protocol for entity to entity interaction. Primary entity information is being passed as UDP/IP datagrams via the UNIX UDP port 3000. All simulation hosts are located on the same subnetwork on the LAN. All simulations are using a 20 X 20 kilometer terrain database so as to orient in a common virtual world. All UNIX workstations are configured with Internet Group Management Protocol (IGMP) and all simulations are using static IP multicast. No reliability via retransmissions is provided at the network transport protocol level as no standard for reliable multicast has yet been adopted by the community [3]. A small number of predefined multicast groups are being used to delineate network traffic to interested users. These groups do not change during the course of the exercise. As in typical DIS scenarios, all simulation applications are acting like senders and receivers. Some simulation applications emit multiple entities (up to 40) while others are responsible for only a single entities behavior. The majority of entities are low speed ground vehicles transmitting DIS 2.0.4 Entity State Protocol Data Units (PDUs) of 1152 bits at an average of two packets per second. These ground entities are controlled by a rule based system that mimics behavior of transportation on four of the SGI simulation hosts. One of the rule-based simulation applications is generating six high speed rotory wing aircraft generating on average six Entity State packets per second. Occasionally, these rotory wing entities emit bursts of 704 bit Fire PDUs with subsequent emission of 832 bit Detonation PDU's (on the order of 20 to 100 packets a second for both Detonation and Fire PDUs). All Entity state based information must arrive at all the designated receivers at the 100 millisecond constraint to remain real-time. The three high speed aircraft simulation emit from 5 to 10 Entity State PDUs per second. Additionally, the aircraft are using experimental radio communication packets for transmitting voice between the users. Pregenerated background voice traffic is being transmitted along with the pilot communications. An air-born control aircraft simulation transmitting voice to the pilots is also issuing the voice DIS packets. These packets are on the order of several hundred bytes and are randomly dispersed through the exercise with occasional bursting. To limit the impact of the voice traffic on simulation applications that cannot process such traffic, a predefined static multicast group is used for all voice communications. One of the simulation applications is providing weather forecasts to exercise participants via a predefined static multicast group. These packets are multicast transmitted at 10 minute intervals due to the very large size of the precipitation and wind data (a total of five megabits of data broken up as individual transmissions of 1500 Byte packets). As fragmentation and reassembly are not provided in the multicast transport layer, the applications fragments the data into manageable packet sizes (i.e., up to the Ethernet Datalink size limitation). The weather data need only arrive at the specified users host at 10 minute intervals to remain real-time. The scenario is periodically compromised when the network traffic exceeds the 10 megabit/second rate. This usually occurs when the radio and weather packets and detonations are all simultaneously occurring. Other loss of network information occurs when the host receiver buffers get overloaded and drop packets when receiving bursts of voice and weather data simultaneously. Exercises that experience such loss are considered invalid and are replayed. 2. This scenario represents a DIS environment maintained by a company as an Intranet using a commercial Wide Area Network (WAN) provider. ... 3. This scenario is an example of a large exercise conducted over the DSI and multiple LAN and WAN segments. ... Scenario 4. Recreations of Historic Battles The year is 2020 or thereabout. The world's major powers have been at peace since the resolution of the Balkans conflict in 1997. Several generations have grown up without the taste of battle. But there is something in the psyche of these generations that yearns for the excitement of engaging an enemy with skill and determination, but without the shedding of their own blood. This yearning has been behind the development of more and more realistic real time simulations. It has culminated in the simulated recreation of historic battles on a grand scale. A culture has grown up around these simulations. Above all they strive for historic accuracy. The simulated planes, ships, tanks, horses, and weapons have the same capabilities as the original. Logistics, planning, and initial conditions are the same. The participants are trained to the same point as their original counterparts. They are tested and qualified before they can participate. Some take on the names and habits real characters. Many assemble at annual conventions to exchange tales and see the latest in simulation equipment. These simulations have become a very popular spectator sport. Millions of viewers watch the battles unfold from any vantage point that they choose. They can go into the command centers. They can tether themselves to any participant and see and hear what he sees and hears . They can tune in to various commentators in different languages for an explanation or critique of what is going on at various points. The recreations are both scheduled and reported on the popular net sport pages. The scenario described below is the recreation of a series of B-17 raids that the US Eighth Air Force made over Europe in 1943. These raids were fiercely and effectively defended by the Luftwaffe and German anti-aircraft artillery (the dreaded flak). The participants are a mix of humans and software models. The humans tend to take the more interesting roles. The software models are sophisticated enough that they cannot be easily distinguished from human participants. Total number of participants roughly corresponds to the number of participants in the original battle and varys between 100,000 and 500,000. Number of spectators ranges in the tens of millions and is governed by the factors that control the watching of any sport. The simulation equipment ranges from simple VR goggles to elaborate cockpits and gun turrets with sophisticated motion and sound cuing. All simulations share visual cues that are indistinguishable from what the unaided eye can see. The participants own or rent the hardware and software. As with any avocation the cost varies depending on taste and finances. Participation is not governed by cost but by the dedication and capability of individuals. The participants and spectators are located throughout the world and are connected on a virtual net that reaches into each participant's and spectator's home. Crew station simulations that are part of one simulated platform (e.g. a single B-17) are themselves distributed. Sophisticated multicasting schemes, clever interest management algorithms, and simulation tricks have effectively removed any limits to the potential scale of distributed simulations. Local bandwidth limitations sometimes restrict what a spectator can see. Dropped packets and latency spikes occasionally cause anomalies, but they are seldom serious enough to effect the outcome of the simulation. Things to do: 1. get feedback on appropriateness of approach 2. Additional descriptive scenarios Acknowledgements: The authors are working under the direction of Michael Myjak (MMYJAK@ist.ucf.edu) and Chris Bouwens (Chris_Bouwens@cpqm.saic.com) of the DIS Communications Architecture Subgroup (CAS) to produce this informational RFC. References: [1] IEEE Standard for Information Technology - Protocols for Distributed Interactive Simulation Applications, IEEE Std. 1278-1993. [2] http://www.herring.com/mag/issue30/games.html [3] http://www.tascnets.com/mist/doc/mcpCompare.html