Calvin, James O., Joshua Seeger, Gregory D. Troxel, Daniel J. Van Hook,
`"STOW Realtime Information Transfer and Networking System Architecture,"
`95-12-061, Twelfth Workshop on Standards for the Interoperability of Distributed Simulations,
`March 13-17, 1995.
`STOW REALTIME INFORMATION TRANSFER AND NETWORKING
`SYSTEM ARCHITECTURE
`James O. Calvin, jcalvin@ll.mit.edu, MIT LL
`Joshua Seeger, jseeger@bbn.com, BBN STD
`Gregory D. Troxel, gtroxel@bbn.com, BBN STD
`Daniel J. Van Hook, dvanhook@ll.mit.edu, MIT LL
`For the RITN program team
`Keywords: Architecture, Bundling, Communications Architecture, Fidelity,
`Local Area Network, Multicast, Wide Area Network
`Abstract
`ARPA’s Synthetic Theater of War (STOW) program faces significant challenges as it builds upon the
`capabilities of today's distributed simulation systems and architecture. These challenges include
`requirements to economically support:
`• greatly increased numbers of interacting entities
`• an enriched synthetic environment supporting dynamic terrain, smoke, weather, electromagnetic
`effects
`• more complex interactions, including those of command forces, EW/ECM, wide area viewers,
`rapidly steerable imaging systems, enhanced sensors
`These and other requirements will severely stress information transfer and processing capabilities.
`Significant advances in Real-time Information Transfer and Networking (RITN) architectures and designs
`are needed to support STOW program goals. Initial steps towards a new architecture and systems design
`were taken and successfully demonstrated as part of the STOW-Europe (STOW-E) exercise, conducted in
`the fall of 1994. These initial steps were reported on at the 11th DIS Workshop.
`This paper describes the approach being taken for the STOW RITN architecture, which builds upon the
`STOW-E approach. The specific topics addressed in the paper include:
`• requirements and system constraints
`• architectural vision: the longer range goal
`• near term architectural approach (bi-level multicast)
`• algorithms for managing information flow, such as data subscription and the use of IP multicast
`• key simulation application interfaces, e.g., quality of service (QoS), resource reservation, etc.
`The architecture and approaches developed in support of STOW will have a significant impact on DIS
`standards development.
`0.0
`Preface
`While the paper lists a set of four authors, it is the
`combined work of the RITN team. Contributors to
`this paper include:
`Dr. Stuart Milner
`CDR Gary Misch
`L. S. (Lee) Kollmorgen
`Lester Foster
`Walter Milliken
`Joshua Seeger
`R. Tanner
`Jim Calvin
`Carol Chiang
`Duncan C. Miller
`Dan Van Hook
`Joshua E. Smith
`Lou Berger
`Tom Tiernan
`Kevin Russo
`Steve Batsell
`Ray Cole
`R. K. Nair
`Barth Root
`Larry Schuette
`Bibb Cain
`Kathleen Ashbaugh
`Kevin E. Boner
`Dave Fusco
`Cynthia Keune
`Mike Newton
`Adam H. Whitlock
`Dr. Milner is the ARPA program manager for
`
`RITN and CDR Misch is the DMSO program
`manager.
`1.0
`Background
`Distributed Simulation is being scaled up along
`several different dimensions through ARPA’s
`STOW (Synthetic Theater of War) program. Not
`only is the number of entities being dramatically
`increased, but the richness of the synthetic
`environment is being enhanced through addition
`of phenomenology such as smoke, dynamic
`terrain, and weather and through simulation of
`electronic warfare/countermeasures and radio
`communication. Introduction of command forces
`and C3I simulation will increase the complexity of
`interactions and behaviors. Finally, the network is
`being scaled in terms of the number of sites, the
`
`BUNGIE - EXHIBIT 1016
`
`0001
`
`

`

`geographic extent, and the degree of network
`sharing by independent users. These and similar
`factors result in large increases in complexity,
`interdependence, and information that needs to be
`exchanged. As a result, significant challenges for
`Distributed Simulation technology and systems
`exist in the areas of configuration management,
`operations, and real-time information transfer and
`networking. While all of these areas are of critical
`importance, this paper focuses on the last
`challenge listed: architectures and approaches for
`real-time information transfer and networking for
`STOW.
`In the initial architecture for Distributed
`Simulation, developed under the SIMNET
`program, all simulation platforms receive all
`information broadcast by all the others. Each
`receiving node is responsible for sorting out what
`information is relevant to it. This simple broadcast
`architecture is no longer adequate. Even if
`sufficient network resources could be employed to
`carry all the broadcast traffic, it is unlikely that the
`simulation platforms would be able
`to
`economically process all the data they received.
`The scaleability of the current architecture is
`limited by this “firehose effect.”
`In the STOW-E (STOW-Europe) exercise,
`conducted in the Fall of 1994, a step was taken
`away from the broadcast architecture towards a
`new architecture. The STOW-E exercise presented
`a number of real-time information transfer and
`networking problems, including wide area
`viewers, severe throughput limitations on
`encryption devices and tail circuits, large numbers
`of entities, limited processing capabilities of many
`participating simulation applications, and limited
`wide area multicast support. To address these
`problems, an Application Gateway (AG) [1] was
`fielded at each network site. The AG, which was
`interposed between each site LAN and the DSI
`WAN, applied a number of algorithms and
`techniques for managing traffic flowing to and
`from each site. The algorithms employed in the
`AG included the following:
`• Culling blocks PDUs considered unnecessary
`for
`the purposes of STOW-E
`from
`transmission over the WAN. Examples
`include transmitter PDUs, Persistent Object
`Protocol transmissions, and PDUs indicating
`collisions between entities on the same LAN.
`• PICA (Protocol Independent Compression
`
`Algorithm) removes redundancy. Bit-pattern
`differences from a reference are transmitted
`from each sender to the receivers. The
`reference is conveyed using a reliability
`mechanism that ensures consistency across
`the system.
`• Grid filtering partitions the terrain into
`regions for which updates are sent at
`different rates in order to accommodate wide
`area viewers. Rate control is accomplished
`through the rethresholding algorithm, which
`uses multiple dead reckoned models for each
`entity in conjunction with transmit threshold
`control to modulate update rates. Regions of
`the terrain for which different update rates
`are needed are communicated between AGs
`by sending grid cell lists. In addition to
`controlling WAN-bound packet rates, a LAN
`filter that uses grids to select and forward
`only relevant updates to each LAN is
`employed.
`• QES (Quiescent Entity Service) removes
`redundancy due to the transmit timeout
`(default is five seconds). QES detects when an
`entity becomes quiescent, informs all remote
`AGs, and stops sending updates over the
`WAN. The AGs at each site then emit
`updates for the quiescent entities onto their
`attached LANs at the transmit timeout rate.
`Should a quiescent entity become active, its
`updates are again forwarded over the WAN.
`• Rethresholding controls state update rates
`over the WAN. Multiple dead reckoned
`models are maintained for each entity.
`Transmit thresholds (position, orientation,
`time) are relaxed to reduce packet rates for
`selected entities. This algorithm is used in
`conjunction with grid filtering to support
`wide area viewers as well as for graceful
`degradation in the event of overload.
`• Bundling combines PDUs into larger packets
`in order to reduce packet rates. A packet is
`transmitted when either a timer expires or
`the packet reaches a maximum size. As a side
`effect, bit rates are reduced since fewer
`packet headers must be transmitted.
`• Overload management and graceful
`degradation are accomplished through load
`leveling, which spreads packet transmissions
`out in time and rethresholding, which
`controls update rates by relaxing dead
`reckoning thresholds.
`
`0002
`
`

`

`These algorithms proved to be very effective:
`traffic was reduced by more than an order of
`magnitude, permitting the STOW-E exercise to be
`successfully supported over a constrained
`network and system infrastructure.
`While the success of the approach taken for
`STOW-E is impressive, much work remains to be
`done in support of STOW. As an initial prototype
`and proof of concept, the STOW-E AG and its
`algorithms must evolve in several directions in
`order to meet the requirements of the STOW
`program. First, the High Performance Application
`Gateway (HPAG) must be able to take advantage
`of network technologies such as multicasting,
`resource reservation, and broadband services that
`will be needed to support STOW. A necessary role
`of the HPAG is isolating simulation applications
`from particular interface and performance details
`of the network, and vice versa. This “impedance
`matching” role decouples simulation applications
`and the network and permits independent
`evolution. Second, new and enhanced information
`flow management algorithms need to be
`developed and incorporated into the HPAG
`and/or simulation hosts in order to handle the
`significant increases in traffic levels and new
`traffic types expected. Along similar lines,
`evolution of the DIS protocol will require support
`for Agents [2] that function as enablers for
`simulation applications. The HPAG, along with
`other systems, will be an execution platform for
`these Agents. Finally, since the STOW program at
`its culmination will deliver an operational training
`system, the Application Control Techniques (ACT
`which includes the HPAG) must be productized
`and extended. ACT must flexibly support legacy
`as well as new simulations. It must also permit
`migration of its functions so as to make best
`overall use of system resources. A significant
`challenge to be faced is the need to construct
`systems that are useful and economical in the
`short term but flexible enough to permit growth to
`address the problems of the longer term.
`2.0
`STOW Network System Requirements
`2.1
`Background
`The primary requirement of the STOW network
`system is to deliver the necessary data to the
`appropriate applications with a minimum of
`latency while consuming a minimum of network
`bandwidth. The STOW network system must do
`this without adversely compromising validity. A
`
`complicating factor for this requirement is that
`technology underlying the STOW network system
`is evolving while the nature of the data to be
`delivered is expanding and changing.
`2.2
`High Level Requirements
`In this section we will enumerate the high level
`requirements of the STOW network system. These
`requirements will address both the short and long
`term requirements STOW network system. When
`necessary, requirement modifications for the 1995
`STOW network system will be noted.
`2.2.1
`The STOW network system must support
`large exercises with elements supplied
`from multiple sites from around the
`world. Exercise targets appear in table
`2.2.1-1.
`Year
`
`Target sites
`
`2.2.2
`
`Target
`Entities
`6
`5,000
`1995
`30
`50,000
`1997
`50
`100,000
`2000
`Table 2.2.1-1: Entity–site support targets for the
`STOW network system
`The STOW network system must permit
`simulation applications to be built and
`run
`independent of exercise size
`(specified entity and object count and
`density). What is meant by this statement
`is that simulation applications are
`specified to operate up to a maximum
`local entity count and density. So long as
`an exercise scenario does not exceed
`these local
`limits,
`the simulation
`application can function independent of
`total exercise size.
`The STOW network system must provide
`mechanisms
`to allow simulation
`applications to control rejection of
`irrelevant simulation data as close to the
`data source as possible.
`The STOW network system must support
`a heterogeneous simulation environment.
`This requirement includes, but is not
`limited to, multiple simulation platform
`types (e.g., Silicon Graphics based, or RS-
`6000 with Evans & Sutherland image
`generators), multiple network types (e.g.,
`ATM, FDDI, Ethernet), and multiple
`simulation types (e.g., live, constructive,
`
`2.2.3
`
`2.2.4
`
`0003
`
`

`

`2.2.5
`
`2.2.6
`
`2.2.7
`
`2.2.8
`
`2.2.9
`
`2.2.10
`
`2.2.11
`
`and virtual) operating simultaneously to
`function as a single system.
`The STOW network system must provide
`a layer of abstraction between the
`simulation application and the actual
`network. This abstraction will permit the
`network to evolve while minimizing
`changes to the simulation applications.
`The STOW network system must provide
`parametric data that will allow better
`utilization of the network by all
`components. Examples of data to be
`provided include the preferred packet
`size, number of multicast groups
`available, maximum packet
`rate
`supported, etc.
`All three components of the system,
`network, agents, and applications, must
`provide health status information to
`exercise and network monitoring
`facilities.
`All
`three components, simulation
`applications, networks, and agents, of the
`system must provide performance
`monitoring and logging facilities.
`It must be possible to reallocate an ACT
`function as required. This will allow
`various portions of the STOW network
`system
`to be placed
`into
`the
`computational platform where they
`provide the best performance for the
`overall system. Decisions regarding
`allocation of function will be based on
`criteria such as cost (recurring and non-
`recurring), latency, robustness, and
`throughput.
`For those applications requiring it (e.g.,
`interacting manned simulators), the
`STOW network system must provide
`application-to-application (or process-to-
`process) data transfer within 100ms,
`80ms of which is allocated to the network
`(LAN and WAN).
`Based on current estimates [3] (that will
`be revised as new information becomes
`available), the STOW network system
`must be prepared to support peak
`offered loads (aggregate) of 140,000
`packets per second and 230Mb per
`
`2.2.12
`
`2.2.13
`
`2.2.14
`
`2.2.15
`
`second. It is anticipated that the various
`Application Control Techniques will
`reduce these offered loads by some, as
`yet unknown, factor.
`(software and
`Essential services
`hardware) which represent single points
`of failure for the STOW network system
`must employ mechanisms to assure rapid
`recovery from failures.
`The STOW network system must
`facilitate current and
`future DIS
`protocols.
`The STOW network system must support
`non-DIS data transfer (e.g., ftp and VTC).
`The STOW network system must support
`the following security requirements:
`is a
`2.2.15.1 Confidentiality of user data
`requirement. User data must not be
`released
`to or accessed by an
`unauthorized person, application, subnet,
`or network. Authorization is based on
`clearance level, community of interest,
`and need-to-know. Both classified and
`unclassified but sensitive user data must
`be protected (at an appropriate level)
`from unintentional or
`intentional
`disclosure.
`2.2.15.2 The network management system has
`associated security requirements. These
`requirements include protection against
`attacks that could affect availability and
`performance of network elements.
`System managers must be authenticated
`before configuration changes are
`allowed. Network management protocol
`data units (PDUs) that result in any
`action must be authenticated.
`2.2.15.3 Key management is an operational
`requirement. The key distribution system
`must protect the keys from disclosure to
`unauthorized entities, ensure that the
`keys were received from the authorized
`entity and were not changed during
`transmission, and also ensure that keys
`are available when needed.
`2.2.15.4 There
`is a requirement for some
`observers to obtain access to data at or
`below their security level (i.e., the stealth
`viewer).
`
`0004
`
`

`

`2.3
`
`2.2.16
`
`The STOW network system must be
`capable of supporting multiple,
`independent, simultaneous exercises. The
`total traffic resulting from multiple
`exercises may not exceed the design goals
`for a single exercise as shown in table
`2.2.1-1.
`User requirements and system
`constraints
`Some user requirements pose difficult challenges
`for the STOW network architecture and the
`techniques used to reduce bandwidth demands of
`simulation applications. In this section, some of
`these user requirements are enumerated. Solving
`many of these problems is not strictly a part of the
`HPAG design, or the STOW network system.
`However, the STOW network system and HPAG
`must be designed with these constraints in mind
`to assure that the user requirements can be
`adequately met. Experiments must be conducted
`(with user input or participation) to quantify any
`adverse effects imposed by the bandwidth-
`reduction techniques. The final selection of
`Application Control Techniques will be based on
`these findings.
`2.3.1
`Validity
`No technique used by the STOW network system
`or HPAG should adversely affect the validity of an
`exercise. However, some techniques, such as dead
`reckoning threshold control and load leveling, can
`have an effect on validity. It is not clear, however,
`what the effect of a small amount of threshold
`control and load-leveling is on an overall exercise.
`Further, the validity constraints will not be the
`same for all types of exercises. Training exercises
`will typically have a less severe validity
`constraints than a test and evaluation exercise.
`Experiments must be performed to determine how
`these techniques may be used and thereby insure
`that use of threshold control and load-leveling do
`not invalidate the results of an experiment.
`2.3.2 All data available everywhere
`The STOW-E exercise did not deliver full-fidelity1
`data for all entities to all sites. Some of the user
`
`1Full-fidelity is defined as the lowest uncertainty data available
`within the simulation system. The thresholds for this full-
`fidelity data are set at exercise initialization time, and are
`traditionally on the order of one meter of positional uncertainty
`and three degrees of orientation uncertainty.
`
`community viewed this a deficiency of the system.
`However, a user requirement for all data to be
`available everywhere is a response to a perceived
`problem rather than a hard requirement. The
`STOW network system must deliver the necessary
`data to allow each player and observer in an
`exercise to perform as if all the data were available
`everywhere. Examples of consumers of such data
`are plan-view displays and after-action review
`(AAR) systems. The requirements and constraints
`of each of these (and other systems) will be
`addressed in later sections.
`2.3.3
`Plan-View Displays
`Plan-view displays (PVDs) provide a two
`dimensional view of the exercise playbox. The
`PVD is an important tool that can provide the user
`with a view ranging from an overview of all or
`major portions of the exercise playbox, to a narrow
`view approximating that of a manned simulator.
`When the PVD operator uses the broad view, it
`would appear that all, or nearly all, data is
`required to support the PVD. However, with this
`broad view, the PVD cannot display the position
`of entities with the same accuracy of a manned
`simulator or when the PVD is used with a
`narrower field of view. As such, the PVD requires
`data about all (or many) of the entities in the
`exercise, but that data can be provided at a
`reduced frequency of delivery. When the PVD is
`operated with a more narrow field of view, the
`normal ACT filtering on high fidelity data can be
`used to support the PVD. The PVD simulation
`application will change the type of data it uses
`based on the operator’s chosen field of view.
`2.3.4
`Stealths
`Another important tool for exercises is the Stealth.
`The Stealth vehicle allows an exercise observer to
`move to any point in the exercise playbox and
`observe the exercise. As such, the Stealth behaves
`like any other vehicle (with the exception of being
`invisible to the exercise participants) and should
`be supported adequately by the mechanisms that
`support all other entities.
`2.3.5
`Logging
`In exercises prior to STOW-E, all PDUs sent
`during an exercise were recorded. In STOW-E, this
`was not so easily accomplished because the AG
`did not forward all PDUs to all sites. Thus, each
`LAN had a unique world view. The solution in
`STOW-E was to record traffic on multiple LANs,
`and then combine the log files after the exercise.
`
`0005
`
`

`

`1995
`1996
`1997
`
`# of WAN mcast
`groups available
`~1,000
`<5,000
`<5,000
`
`created by multiple developers. The interfaces
`ACT will similarly fragment the world view. To
`must be sufficiently well thought out before
`facilitate reconstruction of a single ground-truth
`coding begins so
`that
`they can
`indeed
`log file, the STOW network must provide for the
`accommodate the needed functionality. They must
`synchronization of all logger clocks.
`be sufficiently clearly specified so that programs
`2.3.6 After-Action Review
`written by different teams will interoperate.
`In the past, after action review systems (AAR)
`2.3.8
`Interoperability with legacy DIS and
`have used the data logger as the basis for
`SIMNET systems
`reviewing an exercise. For large exercises, some
`The STOW user community will expect to be able
`units will complete their assignments well before
`to utilize existing assets in STOW exercises. To
`the completion of the total exercise and will wish
`meet such expectations, the STOW network
`to begin their AAR at that time rather than waiting
`system must provide functionality to translate
`for the completion of the exercise. Further, such a
`between the “native” DIS protocol level (DIS 3.X)
`unit may need to examine exercise context outside
`and the immediately previous version of DIS (DIS
`that which was captured by their local logger.
`2.X).
`Under such circumstances, it will be necessary to
`combine some logger files while the exercise is still
`2.3.9 Network constraints
`in process.
`For the next few years the STOW network system
`2.3.7 Heterogeneity
`will be constrained by various components of the
`overall system. Table 2.3.9-1 summarizes these
`The complete traffic reduction system will be
`forecast constraints.
`composed of multiple subsystems and programs
`Bandwidth limits
`Packet rate End-to-end IP WAN
`Backbone
`Tail circuits
`limits
`MCast
`Multicast
`155Mb/s
`n/a
`~200p/s
`Y
`Static
`155Mb/s
`<45Mb/s
`>>200p/s
`Y
`Dynamic
`155Mb/s
`>45Mb/s
`>>200p/s
`Y
`Dynamic
`Table 2.3.9-1: Near term network constraints
`Automatic Target Recognition or Automatic
`Target Queuing system. Typically RSIS systems
`are characterized by a smaller field of view than a
`WAV while still having long viewing range. RSIS
`also have less tolerance for uncertainty in their
`data. An example is the telescopic sight found in
`some F-15 aircraft. The field of regard of a RSIS
`can be rapidly changed (like the spotlight mode on
`a
`JSTARS). Consequently,
`the RSIS has
`characteristics of a WAV with stringent tolerances
`on uncertainty. This is because even though the
`field of view of an RSIS might be small, it has a
`long viewing range and can be re-steered rapidly.
`The RSIS presents a particularly challenging
`problem.
`2.4
`Derived requirements
`2.4.1
`The simulation applications and agent
`components must provide quantitative
`estimates of their predicted flows. This
`information must identify predicted
`destinations and include an estimate of
`how much traffic will be sent to each of
`
`2.3.10 Exercise free play
`The range of possible exercise scenarios will not be
`unduly constrained by the STOW network
`architecture. The STOW network system should
`impose exercise limitations only because of budget
`constraints, not because of architectural
`limitations.
`2.3.11 Wide Area Viewers and Rapidly
`Steerable Imaging Systems
`The STOW network architecture must support
`both Wide Area Viewers (WAV) and Rapidly
`Steerable Imaging Systems (RSIS) simulation
`applications. WAVs are defined as systems that
`have field of view that spans a large geographic
`region. Examples of WAVs include an AWACS
`and a SPY-1 RADAR. PVDs can be an instance of a
`WAV when displaying a coarse resolution display.
`Typically, a WAV has a greater tolerance for
`positional and orientation uncertainty than other
`simulation applications.
`RSIS are systems that form an image to be viewed
`by either a human operator, or by some kind of
`
`0006
`
`

`

`2.4.2
`
`2.4.3
`
`2.4.4
`
`2.4.5
`
`2.4.6
`
`them.
`All ACT functions must be written in a
`manner that promotes portability
`between ACT components and
`computing platforms.
`It must be possible to synchronize clocks
`between various components of the
`simulation system. This requirement is
`derived from 2.3.5.
`The STOW network system must
`provide mechanisms to limit packet
`rates delivered
`to
`simulation
`applications. The goal is to allow the
`simulation application to receive the
`data necessary for proper operation, but
`to not consume excessive amounts of
`the host processor by requiring it to
`handle extra packets, either as
`extraneous packets, or part of the
`required data stream.
`Each simulation application must
`provide a mechanism for determining if
`the application is still functioning
`properly.
`As a complement to the work done on
`the HPAG, an Application Translator
`must be designed and built to add DIS
`3.X functionality to non-DIS 3.X (legacy)
`simulations. A separate design
`interacts
`with
`
`document will be required for this
`device.
`Architecture
`3.0
`This section describes the overall STOW network
`system architecture. We will first define and
`describe the high level system architecture. From
`these definitions, we will describe the long-term
`vision of our objective STOW network system
`architecture. Then, in section 3.3, we will describe
`the baseline system architecture.
`3.1
`High Level Architecture
`At the highest level, the architecture can be
`decomposed into three types of components:
`simulations, agents, and networks. Figure 3.1-1
`illustrates
`these components and
`their
`relationships. Two relationships are shown in the
`figure. The “uses” relationship exists when one
`component consumes or uses capabilities or
`services of another component. The “uses”
`relationship is asymmetric, with one component
`enabling or facilitating the operation of another
`component. In contrast, the “interacts with”
`relationship exists when components exchange
`information in order to carry out their designated
`functions. The distinguishing characteristic of the
`“interacts with” relationship is its symmetry, i.e., it
`is a peer-to-peer relationship. The characteristics
`of each the components in the figure are
`summarized below.
`
`Simu-
`lation
`
`uses
`
`uses
`
`uses
`
`Agent
`
`interacts
`with
`
`uses
`
`interacts
`with
`
`Network
`
`Figure 3.1-1: Component relationship diagram
`
`Component relationships, R2, 8 Feb 95 /jc
`
`0007
`
`

`

`• Network. The network component provides
`communication services for agents and
`simulations. The network component of the
`architecture is used by simulations and
`agents to transfer information.
`• Agents. The agent architectural component
`has two purposes. First, agents provide a
`clean separation between network and
`simulation functionality. This isolation
`permits independent growth and evolution
`of simulations and networks. Second, agents
`collect functionality in order to facilitate
`economical system implementation. Agents
`are used by simulations to enable and
`facilitate simulation processing and
`interactions. In addition, agents may use
`other agents as enablers and facilitators.
`Agents may also interact with other agents.
`The HPAG can be considered an execution
`platform for agents.
`• Simulations. Simulations
`interact with
`simulations to create a virtual environment.
`Information supporting these interactions is
`exchanged by simulations using the services
`provided by the network component. In
`addition, simulations use agents as enablers
`and facilitators.
`This decomposition provides a useful framework
`in which to think about architectural alternatives.
`It provides a valuable abstraction that facilitates
`allocation of requirements and functionality to
`architectural components and clarifies interfaces
`
`and interactions.
`3.2
`System Architecture Vision
`In this section we discuss the long term
`architectural vision of the STOW network system.
`It is important to keep this vision in mind as we
`develop interim systems as stepping stones on the
`path to this eventual system. The practical time
`frame for implementing this vision is debatable,
`but is beyond the 1997 timeframe.
`Figure 3.2-1 depicts a vision of a future system
`architecture
`that supports decomposition
`described in section 3.1. This architecture assumes
`the following:
`• Dynamic, end-to-end, multicast group
`support for thousands of groups with
`dynamic resource reservation.
`• An efficient DIS protocol that effectively
`encodes information and limits transmission
`of this data to what is required for other
`simulations to perform correctly.
`• The network resources are accessed via a
`defined interface not specified by the RITN
`program. These resources are probably
`acquired from a COTS service provider via
`switched virtual circuits (SVC) or a public
`network.
`• No application gateway-like device in series
`with packet streams between LANs and
`WANs.
`
`Wide Area Network
`–(cid:0)SVC/Public network
`– Multicast capable
`Encryption
`Router/Switch
`
`ATM/gigabit multicast
` capable, network level,
` encryption
`
`Agent
`
`Subscription
`Fidelity control
`Quality of Service
`etc.
`
`Legacy system
`translator
`
`Simulation
`Application
`
`Agent
`
`Simulation
`Application
`SAF
`CATT simulators
`JSIM
`etc.
`Figure 3.2-1: Long term network system architecture vision
`
`Architecture vision, R2, 21 Feb 95 /jc
`
`0008
`
`

`

`The allocation of functions falls to one of the three
`components described in 3.1. For example, quality
`of service (QoS) may be allocated to a combination
`of agent and network. As a second example,
`quiescent entities (QES) may be handled directly
`in the DIS 3.X protocol with agent support.
`While the architecture loosely outlined here
`represents a future goal, we must also develop
`interim steps that may be constrained by
`technology, time, and available funds. One such
`interim step is described in the next section.
`3.3
`STOW-97 Application Control
`Functional Architecture
`This section describes the baseline architecture.
`Figure 3.3-1 depicts this baseline architecture. The
`justification for this architecture and the allocation
`of required functions is described in the following
`paragraphs.
`3.3.1 Bi-Level Multicast
`The long term architecture vision makes use of
`large numbers of end-to-end, dynamic multicast
`groups with resource reservation. However, in the
`baseline system, such capabilities will be
`unavailable. For this reason a bi-level multicast
`scheme will be used.
`The HPAGs will provide a high-dynamic
`multicast service with a large number of groups
`by communicating among themselves and
`performing multicast routing using the low-
`dynamic WAN multicast service with a
`constrained number of multicast groups. This
`implementation will not be distinguishable by the
`simulation applications from a “native” wide-area
`multicast implementation.
`It is important to note that this is not a key
`interface; the HPAGs must provide multicast
`service to the simulation applications, but no
`simulation application will ever be aware of how
`this is done or adapt its behavior to conform to the
`scheme in any way. The HPAG will essentially be
`implementing a router, and like all routers, its
`function will be transparent to the applications
`whose data traverses the router.
`3.3.2 Multicast/ Relevance filtering
`Relevance filtering will be facilitated by the use of
`multicast. Each simulation application will send
`packets to the appropriate group, and receive
`packets sent to a set of appropriate groups. Each
`
`simulation application will communicate its data
`requirements to a “subscription agent,” which will
`determine the groups to be used and convey this
`information back to the simulation applications.
`There will be a subscription agent(s) at each DIS
`3.X LAN. The implementation of the subscription
`agents may be done so that the agents do not need
`to communicate among themselves, or it may be
`done in a manner such that the agents exchange
`information with each other. Communication
`between subscription agents will be dependent
`upon the multicast group assignment algorithm in
`use.
`Two proposals currently exist for multicast
`assignment algorithms. First is the playbox grid
`scheme, which assigns a different multicast group
`to each grid square of a playbox. An alternate
`scheme using clustering based on multiple
`parameters such as fidelity requirements, classes
`of data, and geographic proximity could also be
`used.
`For relevance filtering via multicast addresses to
`work, the multicast network infrastructure must
`be able to provide a large number of groups (more
`than 10,000) and low join latencies (less than one
`second). Because such capabilities are not easily
`available today, a scheme to implement them over
`a less-capable network is described elsewhere (bi-
`l