As per Relevance of the word simulation, we have this rfc below:
Network Working Group S.
Request for Comments: 1667 MITRE
Category: Informational D.
MITRE
M.
George Mason
August 1994
Modeling and Simulation Requirements for
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
Executive
The Defense Modeling and Simulation community is a major user
packet networks and as such has a stake in the definition of IPng
This white paper summarizes the Distributed Interactive
environment that is under development, with regard to its real-
nature, scope and magnitude of networking requirements.
requirements for real-time response, multicasting, and
reservation are set forth, based on our best current understanding
the future of Defense Modeling and Simulation
1.
The Internet Engineering Task Force (IETF) is now in the process
designing the Next Generation Internet Protocol (IPng). IPng
expected to be a driving force in the future of commercial off-the
shelf (COTS) networking technology. It will have a major impact
what future networking technologies are widely available,
effective, and multi-vendor interoperable. Applications that
all of their network-layer requirements met by the standard
of IPng will be at a great advantage, whereas those that don't
have to rely on less-widely available and more costly protocols
may have limited interoperability with the ubiquitous IPng-based
products
Symington, Wood & Pullen [Page 1]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
This paper is intended to serve as input to the IPng design effort
specifying the network-layer requirements of Defense Modeling
Simulation (M&S) applications. It is important that the M&S
make its unique requirements clear to IPng designers so
mechanisms for meeting these requirements can be considered
standard features for IPng. The intention is to make IPng's
of wide COTS availability, multi-vendor interoperability, and cost
effectiveness fully available to the M&S community
2. Background: Overview of Distributed Interactive
The Defense Modeling and Simulation community requires an integrated
wide-area, wideband internetwork to perform Distributed
Simulation (DIS) exercises among remote, dissimilar
devices located at worldwide sites. The network topology used
current M&S exercises is typically that of a high-speed cross-
and trans-oceanic backbone running between wideband packet switches
with tail circuits running from these packet switches to
nearby sites. At any given site involved in an exercise, there may
several internetworked local area networks on which
simulation entity hosts are running. Some of these hosts may
executing computer-generated semi-automated forces, while others
be manned simulators. The entire system must accommodate delays
delay variance compatible with human interaction times in order
preserve an accurate order of events and provide a realistic
simulation. While the sites themselves may be geographically
from one another, the simulation entities running at different
may themselves be operating and interacting as though they are
close proximity to one another in the battlefield. Our goal is
all of this can take place in a common network that supports
Defense modeling and simulation needs, and hopefully is also
with other Defense applications
In a typical DIS exercise, distributed simulators
information over an internetwork in the form of standardized
data units (PDUs). The DIS protocols and PDU formats are
under development. The first generation has been standardized
IEEE 1278.1 and used for small exercises (around 100 hosts),
development of a second generation is underway. The
Communications Architecture for DIS specifies use of
protocols
The amount, type, and sensitivity level of information that must
exchanged during a typical DIS exercise drives the
requirements for that exercise, and depends on the number and type
participating entities and the nature and level of interaction
those entities. Future DIS exercises now in planning extend
hundreds of sites and tens of thousands of simulation
Symington, Wood & Pullen [Page 2]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
worldwide. For example, an exercise may consist of semi-automated
individual manned tank, aircraft, and surface ship
interacting on pre-defined geographic terrain. The actual
of these simulation entities may be distributed among sites
in Virginia, Kansas, Massachusetts, Germany, and Korea. The PDUs
are exchanged among simulation entities running at these sites
carry all of the information necessary to inform each site
everything relevant that occurs with regard to all other sites
have the potential to affect it within the simulation.
information could include the location of each entity, its
and speed, the orientation of its weapons systems, if any, and
frequency on which it is transmitting and receiving radio messages
If an entity launches a weapon, such as a missile, a new
representing this missile will be created within the simulation
it will begin transmitting PDUs containing relevant information
its state, such as its location, and speed
A typical moving entity would generate between one and two PDUs
second, with typical PDU sizes of 220 bytes and a maximum size
1400 bytes, although rates of 15 PDUs/second and higher are possible
Stationary entities must generate some traffic to refresh
simulators; under the current standard this can be as little as 0.2
PDUs per second. Compression techniques reducing PDUs size by 50%
more are being investigated but are not included in the current
standard
With so much information being exchanged among simulation entities
numerous locations, multicasting is required to minimize
bandwidth used and to reduce input to individual simulation
so that each entity receives only those PDUs that are of interest
it. For example, a given entity need only receive
regarding the location, speed and direction of other entities
are close enough to it within the geography of the simulation that
could be affected by those entities. Similarly, an entity need
receive PDUs containing the contents of radio transmissions that
sent on a frequency other than that on which the entity is listening
Resource reservation mechanisms are also essential to
performance requirements of DIS exercises: reliability and real-
transmission are necessary to accommodate the manned
participating in an exercise
M&S exercises that include humans in the loop and are executed
real-time require rapid network response times in order to
realistic combat simulations. For DIS, latency requirements
the output of a PDU at the application level of a simulator and
of that PDU at the application level of any other simulator in
exercise have been defined as
Symington, Wood & Pullen [Page 3]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
- 100 milliseconds for exercises containing simulated
whose interactions are tightly
- 300 milliseconds for exercises whose interactions are
tightly coupled [2].
The reliability of the best-effort datagram delivery
supporting DIS should be such that 98% of all datagrams are
to all intended destination sites, with missing datagrams
distributed [3].
While these numbers may be refined for some classes of
data in the future, latency requirements are expected to remain
a few hundred milliseconds in all cases. It is also required
delay variance (jitter) be low enough that smoothing by buffering
data stream at the receiving simulator does not cause the
latency specifications to be exceeded
There are currently several architectures under consideration for
M&S network of the future. Under fully distributed models,
simulation entities rely directly on the network protocols
multicasting and are therefore endowed with much flexibility
regard to their ability to join and leave multicast
dynamically, in large numbers
In some cases, the M&S exercises will involve the transmission
classified data over the network. For example, messages may
sensitive data regarding warfare tactics and weapons
characteristics, or an exercise itself may be a rehearsal of
imminent military operation. This means the data communications
for these exercises must meet security constraints defined by
National Security Agency (NSA). Some such requirements can be met
current systems by use of end-to-end packet encryption (E3) systems
E3 systems provide adequate protection from disclosure and tampering
while allowing multiple security partitions to use the same
simultaneously
Currently the M&S community is using the experimental Internet
protocol version 2 (ST2) to provide resource reservation
multicast. There is much interest in converting to IPv4 multicast
it becomes available across the COTS base, but this cannot
until IPv4 has a resource reservation capability. The RSVP
ongoing in the IETF is being watched in expectation that it
provide such a capability. Also some tests have been made of IPv
multicast without resource reservation; results have been positive
now larger tests are required to confirm the expected scalability
IPv4 multicast. But issues remain: for security reasons, some M&
exercises will require sender-initiated joining of members
Symington, Wood & Pullen [Page 4]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
multicast groups. In addition, it is not clear that IPv4
will be able to make use of link-layer multicast available in
systems, which the M&S community expects to use to achieve
performance necessary for large exercises
3. M&S Requirements for
The identified network-layer service requirements for M&
applications are set forth below in three major categories: real-
response, multicast capability, and resource reservation capability
All of these capabilities are considered to be absolute
for supporting DIS as currently understood by the M&S community
except those specifically identified as highly desirable.
desirable we mean that the capabilities are not essential, but
will enable more direct or cost-effective networking solutions
It is recognized that some of the capabilities described below may
provided not from IPng but from companion protocols, e.g. RSVP
IGMP. The M&S requirement is for a compatible suite of
that are available in commercial products
a. Real-time
DIS will continue to have requirements to communicate real-
data, therefore the extent to which IPng lends itself
implementing real-time networks will be a measure of its
for M&S networking. The system-level specifications for the
real-time environment are stated in Section 2 above
b.
M&S requires a multicasting capability and a capability
managing multicast group membership. These
capabilities must meet the following requirements
- Scalable to hundreds of sites and, potentially, to tens
thousands of simulation platforms
- It is highly desirable that the network-layer
protocol be able to use the multicasting capabilities
link-level technologies, such as broadcast LANs, Frame Relay
and ATM
- The group management mechanics must have the
that thousands of multicast groups consisting of tens
thousands of members each can be supported on a given
and that a host should be able to belong to hundreds of
groups simultaneously
Symington, Wood & Pullen [Page 5]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
- Multicast group members must be able to be added to or
from groups dynamically, in less than one second, at rates
hundreds of membership changes per second. It is not
to predict what special cases may develop, thus this
is for all members of all groups
- The network layer must support options for both sender-
receiver-initiated joining of multicast groups
c. Resource
The M&S community requires performance guarantees in
networks. This implies that IPng must be compatible with
capability to reserve bandwidth and other necessary allocations
a multicast environment, in order to guarantee network
from simulator-to-simulator across a shared network for
duration of the user's interaction with the network. Such
resource reservation capability is essential to optimizing the
of limited network resources, increasing reliability,
decreasing delay and delay variance of priority traffic
especially in cases in which network resources are heavily used
The resource reservations should be accomplished in such a
that traffic without performance guarantees will be re-routed
dropped, or blocked before reserved bandwidth traffic is affected
In addition, it would be highly desirable for the
reservation capability to provide mechanisms for
- Invoking additional network resources (on-demand capacity
when needed
- The network to feed back its loading status to the
to enable graceful degradation of performance
4.
[1] Cohen, D., "DSI Requirements", December 13, 1993.
[2] Final Draft Communication Architecture for
Interactive Simulation (CADIS), Institute for Simulation
Training, Orlando, Florida, June 28, 1993.
[3] Miller, D., "Distributed Interactive Simulation
Issues", briefing presented to the ST/IP Peer Review Panel,
Lincoln Laboratory, December 15, 1993.
[4] Pate, L., Curtis, K., and K. Shah, "Communication
Requirements for the M&S Community", September 1992.
Symington, Wood & Pullen [Page 6]
RFC 1667 Modeling and Simulation Requirements for IPng August 1994
[5] Pullen, M., "Multicast Network Architecture for DIS,
presented to the Networks Infrastructure Task Force",
Mason University, C3I Center/Computer Science, November 10, 1993,
revised November 11, 1993.
5. Authors'
Susan
MITRE
7525 Colshire
McLean, VA 22101-3481
Phone: 703-883-7209
EMail: susan@gateway.mitre.
David
MITRE
7525 Colshire
McLean, VA 22101-3481
Phone: 703-883-6394
EMail: wood@mitre.
J. Mark
Computer
George Mason
Fairfax, VA 22030
Phone: 703-993-1538
EMail: mpullen@cs.gmu.
Symington, Wood & Pullen [Page 7]
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
