home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-pullen-lame-00.txt
< prev
next >
Wrap
Text File
|
1996-09-23
|
13KB
|
297 lines
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
<draft-pullen-lame-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).
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