1. Multiple Federation Taxonomy
Michael Myjak
Vice President, R&D
The Virtual Workshop, Inc.
P.O. Box 98
Titusville, FL

2. Project Goals
To analyze the evolving models of federation development, and indicate where extensions might be provided...
To expand on the scope and variety of federation executions...
And to determine the validity of multiple federation interaction.

3. Background…
HLA supports the interoperation of sets of simulations within the context of a single FOM, using the HLA Federate Interface Specification services provided by the Run Time Interface (RTI).
But this doesn’t say anything about
Compound Federates,
Federation Hierarchies, or
Cross-Federation Relationships!

4. Reaching Beyond the Boundaries
The original developers of HLA realized that some issues were problematic:
Hierarchical or Recursive Federates
Hierarchical or Recursive Federations
RTI-to-RTI interface protocols
So they were simply written out of the HLA specification.
Beyond scope

5. And it came to pass... How did we get to this point?
Are multifederation simulations required?
Security and other multi-level domain models seem to indicate this is so.
Could it be that the pendulum of Abstraction has swung to far to the right?
From
OSI based Interoperable Datagrams and Packets... to
Frameworks and Architectures that only promote interoperability?

6. First, a Little Simulation Archeology
the birth of SIMNET
ARPANET transitioned to the NSF.
The Macintosh had just been released into the marketplace.
We saw the introduction of window systems, the mouse, desktop networking.
Mac Maze, Sim City, etc.
Intel 8086 Computers were Hot!
and Pong was The Thing!

7. Data Link layer Protocol
SIMNET Layered Model
SIMNET
Application
[User’s Application]
SIMNET Protocol
[Custom Protocols]
Association Protocol
Data Link layer Protocol
[e.g., IEEE 802.3]
Hardware

8. The way things stack up... Protocol Layers User’s Application
ref: IEEE
Figure 2: shows a representation of this ISO 7-layer model
User’s Application
Application Layer
Transport Layer
Internet Layer
Data Link Layer
Hardware Layer
Presentation Layer
Session Layer
Protocol
Layers
The foundation of the OSI Model...

9. Simulation Archeology (con’t)
As SIMNET and the Internet evolved
Simulation and Interoperability were still in their infancy.
DIS standardization attempts -
Focus was on transport-level Interaction.
OSI Model was incorporated.
ALSP developers found DIS to restrictive
Evolved a higher level abstraction -
Advanced Distributed Simulation

10. [Standardized Protocols]
DIS Layered Model
DIS
Application
[User’s Application]
UDP / TCP
Transport Protocol
[Standardized Protocols]
Internet Protocol
Data Link Protocol
[e.g., IEEE 802.3]
Hardware

11. Simulation Archeology (con’t)
ASLP evolved 3 unique requirements beyond those identified in DIS
Time Management
Maintain causality by coordinating events.
Data Management
Each simulation application (or application process) uses its own database.
A Common Architecture
Introduced the ALSP Common Module

12. High Level ALSP Model ALSP ALSP Application Application ALSP ALSP
Actor/Translator
ALSP
Common Module
ALSP
Common Module
ACM
ALSP
Basic Engine
ABE

13. High Level Architecture Model
Federate
Application
Federate
Application
Notice the
relationship
here… ?
RTI
Ambassador
RTI
Ambassador
Run Time infrastructure

14. ALSP Layered Implementation
Application
Actor/Translator
ALSP
Common Module
ACM
UDP
Transport Protocol
Internet Protocol
ABE
Data Link Protocol
[e.g., IEEE 802.3]
Hardware

15. Simulation Archeology (con’t)
HLA also retained ALSP’s principle extensions from DIS environments:
The federation has no central node
No server, at least in concept.
Federates can be geographically distributed
They can reside in different locations.
Federate communications use a pre-defined interface resembling message passing in object-oriented design.
Attribute and Interaction Updates.

16. Motivation behind HLA... HLA is a relative newcomer to M&S
Demonstrations have shown:
Support for the reuse of legacy systems.
Usefulness in data acquisition & confirmation.
System integration, including disparate simulation systems.
But where does HLA fit
In the “Open Systems Interconnect” (OSI) Model?

17. DIS and SIMNET Applications
Simulation
Application
Application’s
Network Interface,
NIU, NAPI, etc.
All
Generated Network
Interface code Directly...
SIMNET & DIS
PDUs
UDP / TCP
Transport Protocol
Internet Protocol
Data Link Protocol
Hardware

18. ALSP and HLA “Raised the Bar”
Confederate / Federate
Application
Program
Interface
ALSP Common Module
- or -
Run-Time Infrastructure
UDP / TCP
Transport Protocol
Internet Protocol
Data Link Protocol
Hardware

19. Internetwork Model Layering...
Conceptual Layers
Seen by the
User’s Application
Objects Passed
Between Layers
API to User Applications
Application Layer
Messages & Streams
Transport Layer
Protocol Packets
Internet Layer
IP Datagrams
Data Link Layer
Network-Specific Frames
Hardware Layer

20. Focus On The Application Layer
Well-defined application layer protocol specifications are:
Concise
Clearly Articulated
unambiguous
Application Layer Protocols define two interfaces:
To the “User Application*”
To the Transport Layer Protocol
Comer defines “user application” as either the user, or the user’s application.

21. Application Layer is the Key
In one sense, the application layer protocol is unique* among the other protocol layers -
Only the application layer protocol defines two discrete interfaces:
One to interface with the user’s application, and
One to interface with the lower layer interface.
So, if HLA is an Application Layer Protocol…
then the following architectural examples are all possible.
Excluding the data link and hardware layers, as they also have unique features.

22. Basic HLA Federation The Infamous Lollypop Diagram…
Squared up a bit...

23. 2 Levels of Classification
The most basic level of classification permits Federations to be classified into two broad types:
Bridged
RTI & Federate Bridges
Federate and Federation Proxies
Hierarchical
Containing Component Federates
Proxy Federates (gateways)

24. Bridged Federations
A True Bridge
Inter or Intra-RTI

25. Bridged Federations True Bridge Connects internally between RTI
Understands the RTI to RTI interface
A protocol which here unto is undefined
Requires RTI internal state information
Potential exists to operate using the Federate Interface Specification...
However, this his solution is problematic -
Unclear how multiple yet dissimilar services could be bridged

26. Bridged Federations Federation Proxy (not a Gateway!)
Inter Federate-level Operation
(traffic is “out of band” from the RTI)
Bridges Two or more Federations

27. Hierarchical Federations
Simulation Proxies - Basic Form
Sometimes called Gateways...

28. Hierarchical Federations
Component or Hierarchical Federates
A Federate consisting of Multiple components

29. Hierarchical Federations
Logical view of Joined Component Federates

30. Hierarchical Federations
Components May Also Be Non-Federates

31. Hierarchical Federations
Simulation Proxy between component federates… e.g., DIS Gateway

32. Conclusions
RTI developers need to be aware of special interest Federate and Federation designers.
The “Other” interface to the RTI needs work too!
Policy is easy… it’s the mechanics that need additional support.
Clear and simple need will be the driving factor.