INTERNET DRAFT J.M.Pullen George Mason U. M.Myjak U.of Central Florida C.Bouwens SAIC, Inc. 20 September 1996 Expire in six months Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment 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). Abstract The characteristics of distributed simulation in the Large Multicast Environment are described. Mechanics and rates of data exchange are elaborated. Required network characteristics are described. Using this information, additional capabilities needed to use the Internet Protocol Suite for support of large-scale distributed simulation are enumerated. 1. The Large Multicast Environment The Large Multicast User's Group (LAMUG) was formed to create a consensus-based requirement for Internet Protocols to support Distributed Interactive Simulation (DIS), its successor the High Level Architecture for simulation (HLA), and related applications. The applications are characterized by the need to distribute a real-time application 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. Each such host may simulate a number of battlefield entities that may be as few as one or an many as thousands. The network supporting such a system necessarily will be capable of multicast. 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 system for military training, rehearsal, and other purposes. DIS standards are used for the same purposes by defense and other organizations in other countries as well. More information on DIS can be found in the references. The feature of DIS that drives network requirements is that it is intended to work with output to and input from humans across distributed simulators at both local and distant locations 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 large amounts of data to all participating simulators. Large DIS configurations are expected to place hosts in multicast groups based on sharing the same sensor inputs in the virtual environment. This can mean a need for hundreds of multicast groups where objects may move between groups in large numbers at high rates. DIS real time flow consists of packets of length around 2000 bits at rates from .2 per second per simulator to 15 per second per simulator. This information is intentionally redundant and normally is transmitted with a best-effort transport protocol (UDP), and in some cases 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 between applications end-to-end is 100 milliseconds between any two hosts. At relatively rare intervals events (e.g. collisions between battlefield entities) may occur which require reliable transmission of some data on a unicast basis, to any other host in the system. Other protocols supporting the DIS environment (e.g. Network Time and Simulation Management) may require information transport in addition to the flow of DIS entity-state data. DoD has a goal to build DIS 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 DIS-like 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. The High Level Architecture (HLA) is a development beyond DIS that aims at bringing DIS and other forms of distributed simulation into a unifying system paradigm. Thus HLA has networking requirements at least as demanding as DIS. HLA is still under development, therefore this document will focus on the requirements of DIS. 2. DIS network requirements. a. real-time packet delivery, with a small fraction (less than two percent), of packets exceed an established latency, in no case more than a few hundred milliseconds, in a shared network b. multicasting with thousands of multicast groups that can sustain join/leave in less than one second at rates of hundreds of join/leaves per second c. support for secure networking, needed for classified military simulations d. A high degree of flexibility in constructing networks depending on the working environment, such as leased lines, ISDN, ATM, and/or mobile links on instrumented ranges. 3. Internet Protocol Suite facilities needed and not yet available for large-scale DIS in shared networks. These derive from the need for real-time multicast with established quality of service: a. Requirement: resource reservation available in production systems. Work needed: RSVP seems to be on a path to achieving this, however a mechanism is needed to group streams such that multiple multicast groups can share the same network capacity. The RSVP Working Group recognizes a need for this and is planning to consider it after they complete a draft standard based on their current work (experimental RSVP version 12). Note: Some current DIS networks allow for quality of service in terms of reserved/prioritized bandwidth and/or minimal delay (ST-2 or RSVP) or private dial-up links with bandwidth on demand and compression (ISDN), but no commercial, production system using open standards is available to meet the performance requirements projected above. b. Requirement: resource-sensitive routing to be used with the resource reservation mechanism. Work needed: a routing protocol for IP multicast, derived from the current versions (DVMRP or MOSPF) but sensitive to resource requirements. A new protocol called Quality of Service Open Shortest Path First (QOSPF) has been proposed and a working group is being formed to investigate its potential. QOSPF will work with RSVP. It is likely to require at least two years to develop such a protocol. c. Requirement: IP multicast that is capable of taking advantage of link-layer multicast (such as ATM) for packet replication across multiple logical IP subnets (LIS). Work needed: Extend or replace the current standards-track IP multicast over ATM multicast, which uses a Multicast Address Resolution Server (MARS) to resolve the fact that ATM provides no mechanism to distribute IP multicast group information. It only works within an LIS and hence will not support high-performance, wide-area, shared-use IP/ATM networks in multicast mode. An approach to solving this problem has been developed in the DARPA Real time Information Transport Network (RITN) program and was briefed to the IETF in December, 1995 but no working group is pursuing it. d. Requirement: a hybrid transport protocol that can support best- effort multicast of most data, lightweight reliable multicast of critical reference data, and reliable unicast of occasional data. Without such a protocol the application must become responsible for reliability of transport in the real time multicast environment. Work needed: A Selectively Reliable Transport Protocol (SRTP) has been proposed by the Distributed Interactive Simulation Communications and Security (DIS-CAS) working group. This work needs to be brought into the IETF and pursued there. A new IETF working group on multicast transport has been proposed. Such a group would provide a logical home for SRTP development. e. Requirement: network management for DIS systems. Work needed: Create a DIS/HLA Management Information Base (MIB) for use with the Internet standard Simple Network Management Protocol (SNMP). This could be undertaken by the LAMUG. f. Requirement: a session protocol to start, pause, and stop a DIS exercise over an IP network. Work needed: a new subgroup of the Multiparty Multimedia Session Control working group to investigate use of that session protocol for DIS/HLA. g. Requirement: an integrated security architecture. Work needed: Investigate use of the IPv6 security architecture to meet this need. 4. References [1] Symington et. al, "Modeling and Simulation Requirements for IPng", RFC 1667, August 1994 [2] DIS Steering Committee, "The DIS Vision", Institute for Simulation and Training, University of Central Florida, May 1994 [3] IEEE 1278.1-1995, Standard for Distributed Interactive Simulation Application Protocols [4] IEEE 1278.2-1995, Standard for Distributed Interactive Simulation Communication services and Profiles [5] Deering, "Host Requirements for IP Multicasting", RFC 1112, August 1989 [6] Case et. al., "Simple Network Management Protocol", RFC 1067, May 1990 [7] Moy, "MOSPF: Analysis and Experience", RFC1585, March 1994 [8] Estrin et. al., "Protocol Independent Multicast-Sparse Mode", work in progress (draft-ietf-idmr-pim-sm-spec-06), September 1996 [9] Pusateri, "Distance Vector Multicast Routing Protocol", work in progress (draft-ietf-idmr-dvmrp-v3-03), September 1996 [10] Atkinson, "IPv6 Security Architecture", work in progress (draft-ietf-ipngwg-sec-00), March 1996 [11] Braden et. al., "Resource Reservation Protocol Version 1 Functional Specification", work in progress (draft-ietf-rsvp-policy-arch-12) [12] Zhang et. al., "Quality of Service Extensions to OSPF", work in progress (Internet Draft) June, 1996 [13] Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", work in progress (draft-ietf-ipatm-ipmc-12), February 1996 [14] Bormann et. al., "Simple Conference Control Protocol", work in progress (draft-ietf-mmusic-sccp-00), June 1996 [15] Pullen et. al. "Implementation of A Selectively Reliable Transport Protocol for DIS", Proceedings of the 14th Distributed Interactive Simulation Workshop, March 1996 5. Authors' Addresses J. Mark Pullen Computer Science/4A5 George Mason University Fairfax, VA 22032 mpullen@gmu.edu Michael Myjak Institute for Simulation and Training University of Central Florida 3800 Progress Drive Orlando, FL 32826 mmyjak@ist.ucf.edu Christina Bouwens SAIC Inc. Orlando FL chris_bouwens@cpqm.saic.com