As per Relevance of the word simulation, we have this rfc below:
Network Working Group M.
Request for Comments: 2502 George Mason
Category: Informational M.
The Virtual
C.
February 1999
Limitations of Internet Protocol Suite for Distributed
in the Large Multicast
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The Large-Scale Multicast Applications (LSMA) working group
chartered to produce documents aimed at a consensus based
of the Internet protocols to support large scale
applications including real-time distributed simulation. This
defines services that LSMA has found to be required, and aspects
the Internet protocols that LSMA has found to need
development in order to meet these requirements
1. The Large Multicast
The Large-Scale Multicast Applications working group (LSMA)
formed to create a consensus based requirement for Internet
to support Distributed Interactive Simulation (DIS) [DIS94],
successor the High Level Architecture for simulation (HLA) [DMSO96],
and related applications. The applications are characterized by
need to distribute a real-time applications over a shared wide
network in a scalable manner such that numbers of hosts from a few
tens of thousands are able to interchange state data with
reliability and timeliness to sustain a three dimensional virtual
visual environment containing large numbers of moving objects.
network supporting such an system necessarily will be capable
multicast [IEEE95a,IEEE95b].
Pullen Informational [Page 1]
RFC 2502 Limitations of Internet Protocol Suite February 1999
Distributed Interactive Simulation is the name of a family
protocols used to exchange information about a virtual
among hosts in a distributed system that are simulating the
of objects in that environment. The objects are capable of
interactions and can sense each other by visual and other
(infrared, etc.). DIS was developed by the U.S. Department
Defense (DoD) to implement systems for military training, rehearsal
and other purposes. More information on DIS can be found in [SSM96].
The feature of distributed simulation that drives
requirements is that it is intended to work with output to and
from humans across distributed simulators in real time. This
tight limits on latency between hosts. It also means that
practical network will require multicasting to implement the
distribution of all data to all participating simulators.
distributed simulation configurations are expected to group hosts
multicast groups based on sharing the same sensor inputs in
virtual environment. This can mean a need for thousands of
groups where objects may move between groups in large numbers at
rates. Because the number of simulators is known in advance
their maximum output rate in packets per second and bits per
is specified, the overall total data rate (the sum of all
groups) is bounded. However the required data rate in any
group cannot be predicted, and may change quite rapidly during
simulation
DIS real time flow consists of packets of length around 2000 bits
rates from .2 packets per second per simulator to 15 packets
second per simulator. This information is intentionally redundant
is normally transmitted with a best effort transport protocol (UDP).
In some cases it also is compressed. Required accuracy both
latency and of physical simulation varies with the intended
but generally must be at least sufficient to satisfy
perception. For example, in tightly coupled simulations such as
performance aircraft maximum acceptable latency is 100
between any two hosts. At relatively rare intervals events (e.g
collisions) may occur which require reliable transmission of
data, on a unicast basis, to any other host in the system
The U.S. DoD has a goal to build distributed simulation systems
up to 100,000 simulated objects, many of them computer
forces that run with minimal human intervention, acting as
force or simulating friendly forces that are not available
participate. DoD would like to carry out such simulations using
shared WAN. Beyond DoD many people see a likelihood that
simulation capabilities may be commercialized as entertainment.
scope of such an entertainment system is hard to predict
conceivably could be larger than the DoD goal of 100,000.
Pullen Informational [Page 2]
RFC 2502 Limitations of Internet Protocol Suite February 1999
The High Level Architecture (HLA) is a DoD development beyond
that aims at bringing DIS and other forms of distributed
into a unifying system paradigm. From a distributed
standpoint HLA is considerably more sophisticated than DIS.
example attributes of distributed objects may be controlled
different simulators. From the standpoint of the supporting
the primary difference between HLA and DIS is that HLA does not
for redundant transmission of object attributes; instead it
a "Run Time Infrastructure" (RTI) that is responsible to
data reliably, and may choose to do so by various means
redundant transmission using best effort protocols. It is
to say that any network that can meet the needs of DIS can
HLA by DIS-like redundant transmission, however this approach
the possibility that under HLA some mixture of redundant and
transmission can make significantly better use of network
than is possible using DIS. While HLA, like DIS, does not
use of a multicasting network, it has similar requirements for many
to-many transmission of object attributes at rates in excess of
update per object per second that cannot be met without multicasting
Further, HLA calls for transmission of semantically organized
(for example, groups of objects with similar capabilities such
tanks or aircraft) in this many-to-many context
One solution that has been employed to deal with these challenges
to aggregate the contents of many multicast groups into a
multicast transmission [PuWh95, CSTH95]. Termed "dual-mode" or "bi
level" multicast, this approach takes advantage of the fact
although the amount of traffic in any particular multicast group
vary greatly, the aggregate of all transmissions is bounded. If
traffic is all aggregated into one large flow, an underlying
network can create multicast SVCs with acceptable QoS to support
requirement. It also bounds the network control problem of
joins, in that the joins take place among dedicated collections
routers and across the dedicated SVCs, rather than contending
other LSMAs that may be sharing the same network. But it does this
the cost of adding to the network a new, nonstandard
element that is a hybrid of the Internet and ATM protocols.
address below the requirement to achieve such a result using a
IP network with aggregated reservation via RSVP
The defense distributed simulation community has created a number
multicast-capable networks for various simulated exercises,
from tens to hundreds of simulated objects distributed across
of sites ranging from two to twenty. As the number of objects
increased they have found that building multicasting
potentially supporting thousands of simultaneous multicast
with large group change rates is a hard problem. This defense
is the precursor of similar problems that can be expected
Pullen Informational [Page 3]
RFC 2502 Limitations of Internet Protocol Suite February 1999
commercial networks. Therefore the following sections describe
services required and the shortcomings that have been found in
today's Internet protocols in providing these services, with
intention of informing the IETF to enable it to produce
that meet the needs in these areas
2. Distributed Simulation (DIS and HLA) network service requirements
a. real-time packet delivery, with low packet loss (less than 2%),
predictable latency on the order of a few hundred milliseconds,
buffering to account for jitter (variation of latency) such that
than 2% of packets fail to arrive within the specified latency, in
shared
b. multicasting with thousands of multicast groups that can
join latencies of less than one second, at rates of hundreds of
per
c. multicasting using a many-to-many paradigm in which 90% or more
the group members act as receivers and senders within any
multicast
d. support for resource reservation; because of the impracticality
over-provisioning the WAN and the LAN for large
simulations, it is important to be able to reserve an
capacity that can be dynamically allocated among the multicast
e. support for a mixture of best-effort and reliable low-
multicast transport, where best-effort predominates in the mixture
and the participants in the reliable multicast may be
across any portion of the
f. support for secure networking, in the form of per-
encryption and authentication needed for classified
3. Internet Protocol Suite facilities needed and not yet available
large-scale distributed simulation in shared networks: These
from the need for real-time multicast with established quality
service in a shared network. (Implementation questions are
included in this discussion. For example, it is not clear
implementations of IP multicast exist that will support the
scale of multicast group changes for LSMA, but that appears to be
question of implementation, not a limitation of IP multicast.)
Pullen Informational [Page 4]
RFC 2502 Limitations of Internet Protocol Suite February 1999
3.1 Large-scale resource reservation in shared
The Resource reSerVation Protocol (RSVP) is aimed at providing
and flow-based information for managing information flows at pre
committed performance levels. This capability is generally seen
needed in real-time systems such as the HLA RTI. Concerns have
raised about the scalability of RSVP, and also about its ability
support highly dynamic flow control changes. In terms of
RTI capabilities, the requirement in LSMA is for rapid change
group membership, not for rapid change of group reservations.
is because in existing RTIs the aggregate requirement for all
in a large scale distributed simulation is static. However
current RSVP draft standard for LSMA does not support aggregation
reservation resources for groups of flows and therefore does not
the needs of existing RTIs. Moreover, there is at least one
development underway that intends to use individual,
reservations for large numbers of groups, and therefore will
a dynamic resource reservation capability that scales to thousands
multicast groups
Further, RSVP provides support only for communicating
of the required information flows between simulators and the network
and within the network. Distributing routing information among
routers within the network is a different function altogether
performed by routing protocols such as Multicast Open Shortest
First (MOSPF). In order to provide effective resource reservation
a large shared network function, it may be necessary to have
routing protocol that determines paths through the network within
context of a quality of service requirement. An example is
proposed Quality Of Service Path First (QOSPF) routing
[ZSSC97]. Unfortunately the requirement for resource-
routing will be difficult to define before LSMA networks are
with RSVP
3.2 IP multicast that is capable of taking advantage of all
link layer protocols (in particular, ATM
Multicast takes advantage of the efficiency obtained when
network can recognize and replicate information packets that
destined to a group of locations. Under these circumstances,
network can take on the job of providing duplicate copies to
destinations, thereby greatly reducing the amount of
flowing into and through the network
When IP multicast operates over Ethernet, IP multicast packets
transmitted once and received by all receivers using Ethernet-
multicast addressing, avoiding replication of packets. However
with wide-area Asynchronous Transfer Mode (ATM), the ability to
Pullen Informational [Page 5]
RFC 2502 Limitations of Internet Protocol Suite February 1999
advantage of data link layer multicast capability is not
available beyond a single Logical IP Subnet (LIS). This appears
be due to the fact that (1) the switching models of IP and ATM
sufficiently different that this capability will require a
complex solution, and (2) there has been no clear
requirement for IP multicast over ATM multicast that provides
packet replication across multiple LIS. Distributed simulation
an application with such a requirement
3.3 Hybrid transmission of best-effort and reliable
In general the Internet protocol suite uses the Transmission
Protocol (TCP) for reliable end-to-end transport, and the
Datagram Protocol (UDP) for best-effort end-to-end transport
including all multicast transport services. The design of TCP
only capable of unicast transmission
Recently the IETF has seen proposals for several reliable
transport protocols (see [Mont97] for a summary). A general
with reliable transport for multicast is the congestion
associated with delivery acknowledgments, which has made real-
reliable multicast transport infeasible to date. Of the roughly 15
attempts to develop a reliable multicast transport, all have
to have some problem relating to positive receipt
(ACK) or negative acknowledgments (NAK). In any event, its
clear that there is not likely to be a single solution for
multicast, but rather a number of solutions tailored to
application domains. Approaches involving distributed logging
to hold particular promise for the distributed
application
In the DIS/HLA environment, five different transmission needs can
identified
(1) best-effort low-latency multicast of object attributes that
change continuously, for example position of mobile objects
(2) low-latency reliable multicast of object attributes that do
change continuously but may change at arbitrary times during
simulation, for example object appearance (An
characteristic of this category is that only the latest value
any attribute is needed by the receiver.);
(3) low-latency, reliable unicast of occasional data among
members of the multicast group (This form of transmission
specified for DIS "collisions"; it is not in the current
specification but might profitably be included there.
requirement is for occasional transaction-like exchange of
between two arbitrary hosts in the multicast group, with a
latency that makes TCP connection impractical.);
Pullen Informational [Page 6]
RFC 2502 Limitations of Internet Protocol Suite February 1999
(4) reliable but not necessarily real-time multicast distribution
supporting bulk data such as terrain databases and
enumerations;
(5) reliable unicast of control information between individual
components (this requirement is met by TCP).
All of these transmissions take place within the same large-
multicasting environment. The value of integrating categories (1)
(2) into a single selectively reliable protocol was proposed by
[Cohe94]. Pullen and Laviano implemented this concept [PuLa95]
demonstrated it within the HLA framework [PLM97] as the
Reliable Transmission Protocol (SRTP) for categories (1) through (3).
Category (4) could be supported by a reliable multicast protocol
as the commercial multicast FTP offering from Starburst [MRTW97],
however adequate congestion control has not been demonstrated in
such protocol. There has been some discussion of using the Real-
Streaming Protocol, RTSP, for this purpose, however as the
must be transmitted reliably and RTSP uses a best-effort model,
does not appear to be applicable
In summary, it is clear that a hybrid of best-effort and
multicast (not necessarily all in the same protocol) is needed
support DIS and HLA, and that the low-latency, reliable part of
hybrid is not available in the Internet protocol suite
3.4 Network management for distributed simulation
Coordinated, integrated network management is one of the
difficult aspects of a large distributed simulation exercise.
network management techniques that have been used successfully
support the growth of the Internet for the past several years
be expanded to fill this need. The technique is based on a
called a Management Information Base (MIB) being polled
at very low data rates. The receiver of the poll is called an
and is collocated with the remote process being monitored. The
is simple so as to not absorb very many resources. The
process is called a Manager, and is typically located elsewhere on
separate workstation. The Manager communicates to all of the
in a given domain using the Simple Network Management
(SNMP). It appears that SNMP is well adapted to the purpose
distributed simulation management, in addition to managing
underlying simulation network resources. Creating a
distributed simulation MIB format would make it possible for
simulation community to make use of the collection of powerful, off
the-shelf network management tools that have been created
SNMP
Pullen Informational [Page 7]
RFC 2502 Limitations of Internet Protocol Suite February 1999
3.5 A session protocol to start, pause, and stop a
simulation
Coordinating start, stop, and pause of large distributed exercises
a complex and difficult task. The Session Initiation Protocol (SIP
recently proposed by the Multiparty Multimedia Session
(MMUSIC) working group serves a similar purpose for managing
scale multimedia conferences. As proposed, SIP appears to
sufficient extensibility to be used for exercise session control,
standardized by the IETF
3.6 An integrated security
It appears that this requirement will be met by IPv6 deployment.
shortcoming of the current Internet Protocol (IPv4) implementation
the lack of integrated security. The new IPv6 protocol
implementers to follow an integrated security architecture
provides the required integrity, authenticity, and
for use of the Internet by communities with stringent
demands, such as the financial community. The possibility that
IPv6 security architecture may meet military needs, when
either with military cryptography or government-certified
cryptography, merits further study
3.7 Low-latency multicast naming
Name-to-address mapping in the Internet is performed by the
Name Service (DNS). DNS has a distributed architecture tuned to
needs of unicast networking with reliable transmission (TCP) that
not considered problematic if its latency is on the order of a
or more. The requirement of distributed simulation for agile
among multicast groups implies a need for name-to-multicast-
mapping with latency of under one second for the name resolution
group join combined. This problem has been circumvented in
simulations by using group IP addresses rather than names.
military simulations may be satisfied to communicate using a
mapping from grid squares to multicast groups, growth of
simulation into commercial entertainment cannot be based on such
simple capability. The players in distributed
simulations will want to be organized symbolically by virtual
and role. A low-latency multicast naming service will be required
3.8 Inter-Domain Multicast Routing for
While military LSMAs typically take place within a
administrative domain, future entertainment LSMAs can be expected
involve heavy inter-domain multicast traffic so that players can
supported by multiple service providers. Standardized protocols
Pullen Informational [Page 8]
RFC 2502 Limitations of Internet Protocol Suite February 1999
to support large numbers of multicast flows across domain
will be needed for this purpose. Current work to create a
Gateway Multicast Protocol (BGMP) shows promise of meeting this need
4.
[CSTH95] Calvin, J., et. al., "STOW Realtime Information
and Networking Architecture," 12th DIS Workshop
Standards for the Interoperability Distributed Simulations
March 1995.
[Cohe94] Cohen, D., "Back to Basics," Proceedings of the 11
Workshop on Standards for Distributed
Simulation, Orlando, FL, September 1994.
[DIS94] DIS Steering Committee, "The DIS Vision," Institute
Simulation and Training, University of Central Florida,
1994.
[DMSO96] Defense Modeling and Simulation Office, High
Architecture Rules Version 1.0, U.S. Department of Defense
August 1996.
[IEEE95a] IEEE 1278.1-1995, Standard for Distributed
Simulation - Application
[IEEE95b] IEEE 1278.2-1995, Standard for Distributed
Simulation - Communication services and
[MRTW97] Miller, K., et. al. "StarBurst Multicast File
Protocol (MFTP) Specification", Work in Progress
[Mont97] Montgomery, T., Reliable Multicast Links webpage
http://research.ivv.nasa.gov/RMP/links.
[PuLa95] Pullen, M. and V. Laviano, "A Selectively
Transport Protocol for Distributed Interactive Simulation",
Proceedings of the 13th Workshop on Standards
Distributed Interactive Simulation, Orlando, FL,
1995.
[PuWh95] Pullen, M. and E. White, "Dual-Mode Multicast: A
Multicasting Architecture for Distributed
Simulation," 12th DIS Workshop on Standards for
Interoperability of Distributed Simulations, Orlando, FL
March 1995.
Pullen Informational [Page 9]
RFC 2502 Limitations of Internet Protocol Suite February 1999
[PLM97] Pullen, M., Laviano, V. and M. Moreau, "Creating A Light
Weight RTI As An Evolution Of Dual-Mode Multicast
Selectively Reliable Transmission," Proceedings of
Second Simulation Interoperability Workshop, Orlando, FL
September 1997.
[SPW94] Symington, S., Pullen, M. and D. Wood, "Modeling
Simulation Requirements for IPng", RFC 1667, August 1994.
[SSM96] Seidensticker, S., Smith, W. and M. Myjak, "Scenarios
Appropriate Protocols for Distributed
Simulation", Work in Progress
[ZSSC97] Zhang, Z., et. al., "Quality of Service Path First
Protocol", Work in Progress
4. Security
Security issues are discussed in section 3.6.
5. Authors'
J. Mark
Computer Science/C3I
MS 4A
George Mason
Fairfax, VA 22032
EMail: mpullen@gmu.
Michael
The Virtual
P.O. Box 98
Titusville, FL 32781
EMail: mmyjak@virtualworkshop.
Christina
ASSET Group, SAIC Inc
Orlando,
EMail: christina.bouwens@cpmx.mail.saic.
Pullen Informational [Page 10]
RFC 2502 Limitations of Internet Protocol Suite February 1999
6. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Pullen Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
